feat(jwt): allow getToken in Server Components

[scastiel]

☕️ Reasoning

In Next.js, with new app folder, it might be necessary to call getToken from a server component, with no access to the request req.

This PR aims to reproduce what was done on #5741 for unstable_getServerSession, to allow getToken to be called without req.

import { getToken } from "next-auth/jwt"
import { unstable_getServerSession } from "next-auth/next"

export default async function Page() {
  const session = await unstable_getServerSession()
  const token = await getToken()
  return (
    <>
      <h2>Session</h2>
      <pre>{JSON.stringify(session, null, 2)}</pre>
      <h2>Token</h2>
      <pre>{JSON.stringify(token, null, 2)}</pre>
    </>
  )
}

🧢 Checklist

• Documentation
• Tests
• Ready to be merged

🎫 Affected issues

Fixes #5754

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Updated
next-auth	⬜️ Ignored (Inspect)		Nov 11, 2022 at 3:49AM (UTC)

[scastiel]

Note: this PR should have more checks, update documentation, and probably display some warning. But before going further, if I could get some kind of go signal that’d be terrific 😉

[balazsorban44]

I actually think if we should just document to let the session (and/or maybe the jwt) callback out from authOptionswhen you useunstable_getServerSession`. That's essentially the only difference.

Both read the session cookie, but getToken cannot handle if the session is using strategy: "database". getToken is basically just reading the cookie and decrypting it. unstable_getServerSession does that too, without any options passed to it.

I want our APIs to start converging more, cause right now we have getToken, getSession, useSession, unstable_getServerSession... It would be nice to drop getToken.

UPDATE

Testing locally, I think some adjustments are necessary since the default session callback will still modify the token, so the equivalent would rather be:

const session = await unstable_getServerSession({
  providers: [], // Currently expected, but we could make this optional
  callbacks: { session: ({ token }) => token }, // to bypass the default behavior, see below
})

Here is the default session shape:

next-auth/packages/next-auth/src/core/routes/session.ts

Lines 53 to 60 in 58e30a6

	const session = {
	user: {
	name: decodedToken?.name,
	email: decodedToken?.email,
	image: decodedToken?.picture,
	},
	expires: newExpires.toISOString(),
	}

And to satisfy TypeScript, maybe modify things a bit so the return type of unstable_getServerSession is either Session or the return type of callbacks.session if defined.

[scastiel]

It would be nice to drop getToken.

In that case, how could we get the token? Is it possible to get the token from the session? I need the token.sub info, and I can’t find a way to get it from the session…

Edit: I think you answered my question 😉

[scastiel]

Updated the PR to use unstable_getServerSession with session callback instead to get the token.

And to satisfy TypeScript, maybe modify things a bit so the return type of unstable_getServerSession is either Session or the return type of callbacks.session if defined.

I tried something in the PR. Not fully convinced (seems a bit complex, lots of generics, I wonder if a deeper changer in the API wouldn’t be better).

But the types are correctly inferred when using unstable_getServerSession with session callback :D

At this point I’m keeping the PR for the suggestion, but feel free to close if you don’t want to follow this way 😉

[balazsorban44]

What are your thoughts on #5792 as an alternative to this? Could you review that PR? Created an experimental release for testing too: #5792 (comment)

(Sorry, I've been working on that PR without realizing you were going that direction too 😬 💚)

[scastiel]

What are your thoughts on #5792 as an alternative to this?

I prefer your solution! Just tested the experimental release by replacing getToken with unstable_getServerSession on a personal project, works like a charm 👍

I wonder if the API isn’t starting to get weird though. Encouraging to call an unstable method that is supposed to return a session but that you can configure to return something else… 😅

[balazsorban44]

Hence unstable. We might change the name before finalizing. My dream is to have NextAuth work anywhere. I'm closing this in favor of that PR then. 👍