Http only cookie security vs /api/auth/session

[pawelphilipczyk]

I've read a lot of threads, examples and documentation where access tokens are stored in the session.

In my case I've got a credentials provider flow from which upon authentication I'm storing some user data and an access + refresh tokens from my headless commerce api. This is all working fine.

The remaining doubt I have is this: if we're keeping the next-auth JWT cookie secure from direct client javascript access then what about security of the /api/auth/session route which if I'm not mistaken can be fetched from the same client javascript and receive all the session information I'm passing including access and refresh tokens? Is this something I should worry about or am I missing something :D

Anyway, thank you for this great library!

[balazsorban44]

Hi there! You can be ensured, that correct measurements are taken. Here is the code that runs when you try to contact the /api/auth/session endpoint.
https://github.com/nextauthjs/next-auth/blob/main/src/server/routes/session.js

When you use JWT+cookie for storing your information, it is signed and must be verified on decoding, to make sure the content is not tampered with. Optionally you can also encrypt the cookie, which may result in some size increase though, so it is not applied by default. In general, in applications where you are using NextAuth.js, a short-lived token is the best type of defense. Even with all the steps, we have taken, if someones get hold of the cookie, - with enough time - they will be able to decrypt it and get hold of that information. With a short life though, this can probably almost be eliminated (meaning even if they manage to break it, it will probably already have been expired and the auth server won't accept it).

More info on this:

• https://next-auth.js.org/faq#what-are-the-disadvantages-of-json-web-tokens
• https://next-auth.js.org/faq#are-json-web-tokens-secure

(Note: There is a certain detail in the above link which is incorrect. Currently, all browsers support MULTIPLE 4kb cookies, so you have 4kb space in your session cookie to store any information. In the future we might explore cookie splitting, to increase that size. In most cases, 4kb will be enough)

In addition, we also have protection against CSRF, which you can read about here: https://owasp.org/www-community/attacks/csrf

If you still have concerns though, you can try using a database for storing session info, but it has its own disadvantages.
To prove it, see why JWT can be a better choice: https://next-auth.js.org/faq#what-are-the-advantages-of-json-web-tokens

At the end of the day, it is up to you which one do you chose and aligns better with your application and requirements.

[pawelphilipczyk]

Thanks for the quick and detailed answer!
The part of JWT cookie being signed and all that is related to being trustworthy/unmodified is very much clear.

I guess what I was not sure about was if any 3rd party javascript code could potentially read from /api/auth/session session data (which contains my access and refresh tokens for commerce api).

Until now I was actually storing those tokens in httpOnly cookie and accessing them in nextjs api route only so it was (more?) secured from client javascript.

If I understand FAQ correctly this is my answer:

as the JWT is stored in an server-readable-only-token so data in the JWT is not accessible to third party JavaScript running on your site

Just to see what happens I've uploaded simple js script to surge.sh and included <script> tag with it in my nextjs app to see what happens when such "3rd party" script fetches from /api/auth/session and it looks like it does get all the session data. I'm still not sure this is ok or not :D

[igordanchenko]

Compromised 3rd-party javascript loaded directly into the document === XSS injection === the game is already over. It can modify your DOM model the way it likes; it can talk to your backend API on your user's behalf; it can send users' data wherever it likes, etc. Here is a sample compromised.js based on the next-auth-example to give you an idea.

const tags = document.getElementsByTagName("h1");
for (i = 0; i < tags.length; i++) {
    if (tags[i].innerText === 'Protected page') {
        tags[i].innerText = 'No longer protected page';
    }
}

fetch('http://localhost:3000/api/auth/csrf')
    .then((res) => res.json())
    .then((res) => {
        alert("Obtained csrf token: " + res.csrfToken);
        fetch('http://localhost:3000/api/examples/protected', {
            method: "POST",
            body: JSON.stringify({csrfToken: res.csrfToken}),
        })
            .then((res) => res.json())
            .then((res) => {
                alert('Executed POST request with CSRF token: ' + JSON.stringify(res));
            })
    });

Until now I was actually storing those tokens in httpOnly cookie and accessing them in nextjs api route only so it was (more?) secured from client javascript.

I don't believe it's more secure when it comes to XSS attacks. Rogue 3rd-party script can execute any arbitrary HTTP request against your API, and the browser will happily send your httpOnly cookie along with it.

I'm not a security expert, but it is my understanding that XSS vulnerability means that the game is pretty much over.

[balazsorban44]

A comment on this, make sure that you don't expose your refresh token on the session endpoint, even if it is stored in the session cookie! You can use the session callback (check the docs) to expose only the stuff you need! For access tokens available from the client, it is always a good idea to have a short lifitime.

[advantiot]

Continuing this thread since the author had a great question. My question may be a level lower, but it would be really great if someone could advise on the best approach to implement the scenario described below:

I am using Google OAuth as the provider. I first do a client-side Google auth, followed by a server-side Google Auth. Finally, I validate the user against my own database and generate a custom application-specific JWT that needs to be stored on the client as an httpOnly cookie and sent with every subsequent API request to my backend for validation.

I am using the next-auth callbacks (signIn is where I call my API to get the custom token, jwt where I add it to the token, and session where I set the updated token into the session) and everything is working upto the point where I need to set an hhtpOnly cookie. I've read many possible approach suggestions but could not find any addressing the callback approach.

Next-auth is a great library but this scenario has me stumped for a couple of days now. Unlike with the rest of the application logic, with authentication, unless you have your approach is validated you keep wondering if you have left any open doors.

[El-Nazy]

I believe this could help you with that

https://stackoverflow.com/questions/67594977/how-to-send-httponly-cookies-client-side-when-using-next-auth-credentials-provid