How can I access the HTTP request from a server component?

[leodip]

Hi,

How can I access the http request from my server component (using app router)?

My goal is to be able to get the JWT token from next auth.

The util method to get the JWT token in next auth requires the request passed in as parameter.

await getToken({ req });

But how to get that request ("req"), from the server component?

I appreciate any help with this.

Thanks

[nicksan222]

You should use the getServerSession() method.
Here's my implementation

import { getServerSession } from "next-auth/next"

export default async function Page() {
  const session = await getServerSession();

  // Your component
}

With this you can access all the infromations about the user through SSR and Server Components.

[leodip]

Thanks @nicksan222

For that to work I would need to attach the access token to the session.

That would expose the access token client side. I'm not sure if it's a good idea? See my other question - nextauthjs/next-auth#7886

My idea was to NOT attach the access token to the session, keep the access token server side only, and read the access token (on the server) using this utility function:

await getToken({ req });

The problem is, I don't have access to the request when I'm in a server component. So I can't call getToken.

[hesalx]

@leodip getServerSession has a special case for React Server Components (RSC). It does not require req and/or res because it accesses Next 13 APIs directly: https://github.com/nextauthjs/next-auth/blob/a79774f6e890b492ae30201f24b3f7024d0d7c9d/packages/next-auth/src/next/index.ts#L192

There is a section in the documentation about this: https://next-auth.js.org/configuration/nextjs#in-app-directory

It appears, however, that getToken has not been updated yet. If you look at the source of getServerSesssion you may notice that they simply fake the req with headers and cookies from next/headers. Perhaps, you can do the same to provide req to getToken in your Server Components.

[hesalx]

Perhaps something like

    const { headers, cookies } = require("next/headers")
    req = {
      headers: Object.fromEntries(headers() as Headers),
      cookies: Object.fromEntries(cookies().getAll().map((c) => [c.name, c.value])),
    }
    const token = await getToken({ req });

[leodip]

@hesalx thanks a lot for your input. I appreciate it.

The workaround you proposed for getToken in server components didn't work for me, unfortunately.

If I use your code, with Next Auth, and I do a token refresh in the JWT callback, when it gets to this getToken call, I still get the old token (from before the token refresh), not the new/refreshed one.

I've decided to assign the access token and id token to my session, but with a (manual) symmetric encryption. Yes they are going to be sent to the browser, but at least in an encrypted way.

I wish there was a more elegant solution to this 😐

[hesalx]

That is because getServerSession() calls the session() callback which calls the jwt() callback with the decoded token.
While getToken() simply returns the decoded token.

That means that getServerSession() is able to return a value based on a call to jwt() within the same request, although you have to go through session().

However, this should not be a concern at all. Ask yourself what should happen if the browser initiates 2 API requests in parallel, but one of them refreshes the token? Or if the second request starts later but before the response to the first one was received?

The answer is that you refresh tokens a bit ahead of time. There will be a short window when two tokens are valid at the same time, but one of them will expire very soon anyways.

There is only one session cookie here. If you see the old token after refresh it only means that the request was made before a refreshed token was received by the browser. It also means that any subsequent request will necessarily have the new token.

After all, if you make a decision to refresh the token, the request is by definition sufficiently authenticated and the refresh is authorized. Otherwise you would simply log out the user. That means that you don't really need to worry about reading the new token within the same request as long as you have successfully set it (via jwt() callback).

If it's for any reason not possible in your case to have tokens with overlapping lifetimes (such as when you refresh the token the old one becomes invalid immediately so it's unusable within the same request for API requests), then it indeed becomes a bit more tricky and I would too wish for a better request-local storage to exist in App Router to synchonize such changes.

[leodip]

@hesalx thanks for the detailed explanation.

I have currently added the tokens to the session, encrypted (manually), but I think you're right, I could also introduce a margin to refresh the token a bit ahead of time. That could be more elegant.

[aneeshksoft]

Did you find a better way than attaching the access token to the session?