How do you use numeric user id with next-auth?

[dillanjwilding]

Question 💬

I'm relatively new to NextJS and NextAuth but in other software development it's common to have auto-incrementing primary key IDs for tables. Unfortunately, I couldn't get that working with a simple boilerplate app such as T3 stack with NextAuth as it seems the User id (DefaultUser in next-auth/core/types.d.ts and AdapterUser in next-auth/adapters.d.ts) TypeScript type is hard-coded to string so we're forced to use UUIDs.

I tried to extend NextAuth's types in a next-auth.d.ts file to support numeric IDs but it doesn't seem like TypeScript supports overwriting types and it made a union type instead.

import { DefaultSession, DefaultUser } from 'next-auth'

declare module 'next-auth' {
  interface User extends DefaultUser {
    id: number;
  }
  interface Session {
    user?: {
      id: number;
    } & DefaultSession['user'];
  }
}

Which seems to work most places except in [...nextauth].ts where it is giving me this error:

Type 'string | number' is not assignable to type 'number'. Type 'string' is not assignable to type 'number'.ts(2322)

On the session.user.id = user.id line in this section of code:

export const authOptions: NextAuthOptions = {
  // Include user.id on session
  callbacks: {
    session({ session, user }) {
      if (session.user) {
        session.user.id = user.id
      }
      return session
    }
  },
  adapter: PrismaAdapter(prisma),
  providers: []
}
export default NextAuth(authOptions)

The TypeScript error goes away if I delete the id: string; line from the AdapterUser from next-auth/adapters.d.ts which then falls back to id: number; because I set that on User.

export interface AdapterUser extends User {
    id: string; // <-- I removed this
    email: string;
    emailVerified: Date | null;
}

Ultimately after struggling with it for a while I asked on StackOverflow and the took the response as a solution (i.e. do what I did and then do a type check to filter out string IDs from the string | number type) and that's what I've been using but I'd like to bring this problem to your attention and help working on getting a more ideal long term solution.

How to reproduce ☕️

It's been a while and I'm pretty sure you'd run into this problem with a NextJS app using NextAuth with a numeric/integer User ID but how I did it was:

1. npm create t3-app@latest
2. Select TypeScript
3. Enable NextAuth, Prisma, Tailwind, tRPC packages
4. Add NEXTAUTH_SECRET to .env
5. npm run build
6. npm run start

The app starts fine but TypeScript still things User IDs are strings even though they are stored as integers and should be type number so add "next-auth.d.ts" to tsconfig.json "include" array and copy this into the next-auth.d.ts file:

import { type DefaultSession, type DefaultUser } from 'next-auth'

declare module 'next-auth' {
  interface User extends DefaultUser {
    id: number;
  }
  interface Session {
    user?: {
      id: number;
    } & DefaultSession['user'];
  }
}

Now the NextAuthOptions have TypeScript errors. It seems since I encountered this last create-t3-app has done an update and reorganized so I'm seeing type any errors but I'm pretty sure after you clean those up that you'll see the underlying problem about string User IDs not supporting numeric/integer User IDs. I'll try to put together an example repository to showcase the problem.

Contributing 🙌🏽

Yes, I am willing to help answer this question in a PR

[taylor-lindores-reeves]

+1 should be a number. I have defined custom types in next-auth.d.ts as OP has but no luck overriding AdapterUser.

[dillanjwilding]

@leafyshark That's the error I encounter in my project too. My post here I tried to replicate again from scratch. You should check out my StackOverflow question about this; it won't solve the underlying NextAuth TypeScript problem, but it's a workaround I've been using.

[taylor-lindores-reeves]

I decided to go with cuid() string in Prisma schema as this was bothering me...

[abbasyadollahi]

Just adding a visual of the resulting merged type for id becoming number | string when using module augmentation.

Here's my next-auth.d.ts.

declare module "next-auth" {
  interface User {
    id: number;
  }
}

Another issue with module augmentation is that it doesn't allow for property erasure. So in the case above, even if I set my User interface to only contain an id: number property, there's no way to remove the other attributes (email, name, image) that come from NextAuth's DefaultUser interface.

Ideally there'd be a way to tell NextAuth what the definition of a User looks like and it could be used throughout all the other provider's fields (for example user property in signIn callback params, return value in authorize callback, etc.). Possibly something as simple as NextAuth leaving the DefaultUser blank could work?

[dillanjwilding]

If we could provide a User type to NextAuth and they provide a DefaultUser that could satisfy our desire for numeric IDs.

[Mark2M]

Isn’t using an auto-incremented integer for a userID generally bad practice, at least if it’s exposed in any way? I.e. it’s easy to just add or subtract to get another users ID. This was an issue for the UKs Home Office passport application page a couple of decades ago. Note they had it embedded in a query string so you could just change the number and see someone else’s application.

[dillanjwilding]

I'd argue your example is bad security, not bad database design patterns. Using auto-incrementing IDs is a relatively common practice and, much like other design patterns, developers must take the appropriate steps to secure their code. I think the NextAuth library shouldn't force you to use any particular way but leave that up to the developers themselves.

As far as if auto-incrementing IDs are used in the industry/wild, not only was I taught throughout University to use them but also, for better or worse, every enterprise software company I've worked at since used them.

[Mark2M]

Correct… I do the same with SQL and apps on closed networks or where there’s no chance a user can see or manipulate the ID. All I was pointing out is that you shouldn’t expose an auto-incremented PK anywhere that a user can simply try another number.

In the case I mentioned above the Home Office ignored a report about exposing other users data for two years and didn’t do anything about it until Davy Wynder (if memory serves) contacted them and published the fiasco in PC World magazine.

I should have been more explicit about the context perhaps…

[dillanjwilding]

My pushback is because potential security concerns about bad implementation shouldn't have much weight on wanting to have NextAuth support a standard practice in the industry. With many libraries, the security of the entire codebase isn't inherited from the libraries used. Any leakage of IDs is outside NextAuth so NextAuth shouldn't make decisions limiting their support.

[Mark2M]

Mine was a pointless post perhaps… Just a knee jerk reaction as a couple of places I worked were a little “particular” about that sort of thing, and it was a good few years ago…

[mp3por]

For me this makes the whole library unusable. Having numeric IDs is common and there is no problem security problems with it - my IDs are very large numbers, same as UUIDs but instead of strings they are numbers. However the type of the user ID is hardcoded in the whole library since the library relies on the USER ACCOUNT SESSION relationships and in all of them the ID is hardcoded to string. I tried to override the however there are too many places so I stopped since I don't want to do this again if you change something.

Please add support for numeric IDs.

[dillanjwilding]

There are a couple of workarounds that I've been using but I agree that the library shouldn't make these kind of decisions for developers. I created this issue hoping to discuss possible solutions and bring it to the attention of the library's maintainers but so far no luck. It's unfortunate that this seems to be the library of choice for facilitating authentication for NextJS and T3 apps and maintainers are unresponsive.

[robertotcestari]

+1 to be possible to have numbers as IDs.

If NextAuth wants to be as agnostic possible it should not enforce against a very usual industry practice. Albeit theoretically strings could be more secure, this does't mean - in any way - that using autoincrement will make my app insecure.

[adriangalilea]

It's not just user id's, it's the whole tables that forces you to create, at least with adapters.

I have to create 4 tables when I want to use mine, just to satisfy the lib, then it's forced on you what type of id is being used and the naming both on the fields and tables, then when you want to customise it, it's pretty much impossible and riddled with // @ts-ignore

I understand auth has complexities and allowing freedom can come with costs, but I can't understand why I have to create 4 tables and methods I'll never use, nor bend something as sacred as my primary key on my users table just to satisfy an auth lib, plus being absolutely impossible to override any of this questionable defaults in a clean manner.

[christianstamati]

+1 🙄

[Commando-Brando]

Yeah I would have thought int id would be a no brainer. UUIDs are 128 bytes vs storing a int id is only about 4 bytes. Would really like to see choosing the type of Id as part of the API. UUIDs are more common for distributed databases, most people using NextJs are not at the level of scale where UUIDs are really useful and so just seems like storage waste to me to use UUIDs at this point

[MANTENN]

I ended up overriding the function on the object. It is not clean but can be customized:

const AuthKnexAdapter = KnexAdapter(db)
AuthKnexAdapter.getUser = async function getUser(id: string) {
  const dbUsers = await db('User').select("*").where({ uuid: id }).limit(1)
  if (dbUsers.length == 0) return null
  return dbUsers[0]
}
AuthKnexAdapter.getSessionAndUser = async function getSessionAndUser(sessionToken: string) {
  // Get a session row based on the given token
  const dbSessions = await db("Session")
    .select("*")
    .where({ sessionToken })
    .limit(1);

  // If no session was found, return null
  if (dbSessions.length === 0) return null;

  // If session exists, get the user data for that session
  const dbUsers = await db("User")
    .select("*")
    .where({ uuid: dbSessions[0].userId })
    .limit(1);

  // If no user was found, return null
  if (dbUsers.length === 0) return null;

  // Return the session and the user data
  return { session: dbSessions[0], user: dbUsers[0] };
}