How can I access the user ID in the api route?

[dhuber666]

Hi guys,

My question:

I want to access the current authenticated user that hits /api/anyroute . The closest I got was with this helper function:

const session = await getSession({ req });

But it doesn't contain the id. Just the name, email (but its null) - this is the one user i logged in with (through github).
I want to either have the email or id because thats the only way I can use it in my database.

For example when a user hits /api/todo/new I want to create the todo and I want to store the user id or email into this todo. But right now I don't know why.

Have I missed something in the docs?

I use next.js with prisma adapter.

[alaeddine119]

I think you can do something like this

const session = await getSession({ req });
const currentSession = await prisma.session.findUnique({
        where: { accessToken:session.accessToken) },
    });
const user = await prisma.user.findUnique({
        where: { id: currentSession?.userId },
    });
const userId = user?.id

but I'm not sure if this is the optimal way.

[YuriGor]

I also stuck with such a simple task.
I started working with official demo next-auth app, so in pages/api/auth/[...nextauth].js I found callbacks section and "session" callback inside.
Comments are suggesting to add any custom fields there.
there are two args in this callback: session and user
user has no id but it has 'sub' prop and this prop value matches the id in mongo/users table (I use mongo provider)
So now I am wondering is such an esoteric way to solve such a trivial task as getting user id is really correct?
Am I at risk using this 'sub' user property?

[iaincollins]

Hi there!

The sub (subject) RFC 7519 should map to the user ID.

If you use a query in Prisma (as above) you should be get the User ID from the userId property of the session object.

We don't return the User ID from getSession() by default as it's treated as a private property, but it should be possible to return the full User object in the session if you wish to, using the session callback: https://next-auth.js.org/configuration/callbacks

callbacks: {
    session: async (session, user) => {
      const customSession = session
      customSession.user = user
      return customSession
    }
}

[balazsorban44]

Iain's answer here is the correct answer.

[giuseppeg]

@iaincollins @balazsorban44 hi! Is the session callback the right place to enrich the session object with additional access tokens for other services?

I have a 3rd party service that generates access tokens with expiration so I am wondering if you'd recommend to create another database table for ThirdPartyServiceSessions where I store the access tokens and then in the session callback retrieve the access token by userId.

[YuriGor]

In RFC you mentioned this prop is described as "OPTIONAL",
so is it safe to use "sub" property for this purpose and it's not going to disappear in then future next-auth versions?
Then I will keep using it, as it's already working solution.

[iaincollins]

Happy to confirm we have no plans to remove the sub property to User ID map from the JWT.

As the sub token is part of the spec for claims in a JSON Web Token (RFC 7519) and how we are using it seems like a good fit for the use case, I wouldn't imagine it changing and is safe to rely on it being there.

It was originally implemented as user.id in the JWT, but that was before we updated to reflect the claims spec in RFC 7519. That was a one off breaking change because the original implementation I did wasn't RFC compliant.

NB: I don't think we will want to move to surfacing the User ID in the session by default as exposing user ID's client side could be an edge case security issue and/or GDPR data protection issue for some folks, such as for sites with third party scripts that would be able to read it - so I recommend we leave that one as choice for folks to explicitly expose client site.