Is it secure to expose the access token in session callback?

[leodip]

Hi,

I'm assigning the access token to my session callback, like this:

async session({ session, user, token }) {
      session.roles = token.decoded.realm_access.roles;
      session.access_token = token.access_token;
      session.id_token = token.id_token;
      session.error = token.error;
      return session;
    },

When I use my application, I can see there's a network request to get the session, and the access token can be seen in the response there. The access token is sent to the client (browser).

Is my access token secure if it's sent to the browser in an HTTP request?

Thanks

[leodip]

Anyone?

[hesalx]

This does not look right.

The session data returned to the client does not contain sensitive information such as the Session Token or OAuth tokens. It contains a minimal payload that includes enough data needed to display information on a page about the user who is signed in for presentation purposes (e.g name, email, image).

https://next-auth.js.org/getting-started/client#sessionprovider

I assume, since you are asking this, you are not using the token on the client side and do not need it there.

There are niche use cases of having credentials on the client-side, however, the only mechanism of storing arbitrary credentials in a browser designed with the appropriate security and threat model in mind is a cookie with the httpOnly attribute. In other words, how the classical session works. And this is how it actually works by default under the hood with next-auth, otherwise you can forget about server-side rendering (of logged-in pages).

If you come from a backend development background there may have been a confusion due to the use of the common term "session". The functionality provided by useSession() and the session callback is not equivalent (in terms of persistence and security) to a session on the backend. It's only a part of what consistutes an actual session, the part to let the client-side app be aware of the presence of a session.

A rough counterpart of a traditional backend session in next-auth would be the jwt callback:

This callback is called whenever a JSON Web Token is created (i.e. at sign in) or updated (i.e whenever a session is accessed in the client). The returned value will be encrypted, and it is stored in a cookie.

https://next-auth.js.org/configuration/callbacks#jwt-callback

What you have set in the token can then be accessesed server-side only with the getToken() helper, such as when you want to use the stored token in /api calls, getServerSideProps, etc.: https://next-auth.js.org/tutorials/securing-pages-and-api-routes#using-gettoken

[hesalx]

Looks like this was an attempted workaround due to some changes and limitation of the App Router.
I will keep the answer above for anyone with concerns regarding handling client-side credentials.

For those who are struggling with the App Router, indeed there appears to be an inconvenience (at the very least) of working with the session server-side with the App Router. See the related question: vercel/next.js#52006

[js-jslog]

There is surprisingly little clarity on this question, even after all this time. Not that @hesalx answers here and in vercel/next.js#52006 aren't comprehensive, but when you read things like this in the next-auth docs you do get the impression that auth tokens in session objects is ok:

The session callback is called whenever a session is checked. By default, only a subset of the token is returned for increased security. If you want to make something available you added to the token (like access_token and user.id from above) via the jwt() callback, you have to explicitly forward it here to make it available to the client.

• https://next-auth.js.org/configuration/callbacks#session-callback

But there is absolutely a security concern here, if not a downright vulnerability. There are 2 potential vulnerabilities:

1. Transmitting the session object over http. If you are not securing the transport then you are vulnerable to sniffing attacks.
2. Making the received session object available for a xss attack in the browser itself.

The xss attack point is the one which most concerned me, and initially seemed like an unavoidable consequence of putting secrets in the session object. I then thought I understood how to avoid making the session object available for an xss attack, which explained to me why the next-auth docs left session storage of access tokens on the table. I have finally come back around to thinking that it's vulnerable to attack. I'm tempted to believe that I'm wrong at this last step, but I don't think so.

The concern is that if a session is delivered to your browser, and then your client-side application code has access to this session object, then it probably follows that other 3rd party code that you're running in your project (whether it's part of the bundle or even loaded from 3rd party addresses), will have access to that session object too.

My initial conclusion was then that this explains why next-auth performs a request for every instance of useSession that it finds. So that it doesn't have to store that object anywhere that any 3rd party code could read it. If developers make sure that they are acting on the output of useSession without storing the access token in any context that 3rd party code could access then there's no vulnerability. You are protected by the private scope of the function which is calling useSession.

So that might be the answer or there might be another answer to explain why session stored access tokens might be acceptable, with the right care.

However, I still see a vulnerability, not during or after the application code processing of the session object response, but during it's conveyance in to the useSession calling context in the first place. It is simple for a 3rd party to monkey-patch the fetch function which I believe next-auth will be using to make the request. I'm sure there are other clever things that we should worry about at that boundary. This is JS afterall and event listening is in it's dna.

So I'm left feeling like perhaps there are ways of having a session stored auth token, but even if the fetch monkey-patch issue I've described there isn't a vulnerability (and I really don't see how it isn't), then you still better be careful about how you are handling your session contents after receipt if any of it is secret.

Please correct me if I'm wrong on any of this. I've only been looking in to it for a morning and the lack of hardline advice against this on the dicussion forums and docs makes me think I must be wrong, but my experiments tell me I'm not.