Custom cookie creation (size limitation workaround)

[digitalhank]

Summary 💭

Due to the size limitations of cookies, i cannot store both the refresh & access token i am receiving from Cognito in the session cookie. It would be incredibly favourable if the library allowed you to a create cookies arbitrarily so that i for instance, could store the refresh token inside a separate cookie.

Edit - i realize this is fairly trivial to implement yourself but it would be nice if the library offered this feature oob.

[balazsorban44]

Thank you for this issue. To overcome this, currently you could utilize a database adapter. We offer quite a few options:

https://next-auth.js.org/adapters/overview

Would be also interesting to know if you are interested in creating a PR for this with your ideal implementation? 🙂

Ideally you could fill out the entire issue template you probably skipped, so others can evaluate your suggestion as well.

[mtt87]

Out of curiosity how long are the cognito access_token and refresh_token?
I'm using another oAuth provider and I can easily fit both in the session cookie to be honest.

[digitalhank]

@balazsorban44 thank you but unfortunately our service does not store any data.

[digitalhank]

@mtt87 refresh token is about 1700 b and the session token, which consists of a few profile properties & the access token is around 1850. total size is below chrome's limit but the browser was still printing warnings.

[balazsorban44]

would be interesting to know what is inside the access token? We use IdentityServer 4, and by not adding identity claims to the access token, we could spare a lot of space.

Could you share your [...nextauth].js file?

[digitalhank]

see here - https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html

[dennervidal]

@digitalhank can you share your current solution for this? I'm facing the same issue using keycloak provider

[digitalhank]

You should not allow sensitive cookies to be accessed by the client. Utilise the httpOnly: true flag when creating your custom cookie. The cookies generated by the library already do this.

[digitalhank]

Additionally, i would avoid retrieving sensitive data when invoking getSession(). This is unavoidable if your app is purely client based & the services you depend on reside outside your domain. If that is not the case, I would recommend either proxying your calls through a nextjs api route or hosting a middlelayer service (think bff) on the same domain as your client.

[balazsorban44]

Perfect explanation by @digitalhank.

[TonyBrobston]

You should not allow sensitive cookies to be accessed by the client. Utilise the httpOnly: true flag when creating your custom cookie. The cookies generated by the library already do this.

I'm not sure I follow. How do I not allow cookies to be accessed by the client?

Here is code for setting the cookie:

cookies.set('refresh_token', account.refresh_token, {
    expires: date,
    httpOnly: true,
    overwrite: true,
    sameSite: 'strict',
});

I have httpOnly: true set, however I see the refresh_token in Chrome Developer tools -> Application -> Cookies -> my local url

Am I doing something wrong?

[digitalhank]

Your configuration looks fine. The Chrome dev tools allow you to inspect each cookie attached to your instance, that doesn't mean your client is able to access said cookies. Try running await window.cookieStore.getAll() in your Chrome dev console and you'll see exactly what cookies your client can access.

A server on the same domain would be able to access every cookie you see in Application -> Cookies.

Read more about cookies here

[digitalhank]

@dennervidal something like this

import NextAuth from 'next-auth'
import Cookies from 'cookies'

const setRefreshCookie = ({ cookies, refresh_token }) => {
    const date = new Date()
    const time = date.getTime()
    const expireTime = time + 24 * 60 * 60 * 1000 * 30 // 30 days
    date.setTime(expireTime)

    cookies.set('refresh_token', refresh_token,
        {
            sameSite: 'strict',
            overwrite: true,
            expires: date,
            httpOnly: true
        })
}

const Auth = (req, res) => {
    const cookies = new Cookies(req, res)

    return (
        NextAuth(req, res, {
            secret: process.env.JWT_SECRET,
            callbacks: {
                async session(session, token) {
                    if (token) {
                        session.user.last_name = token.last_name
                        session.user.first_name = token.first_name
                        session.user.role = token.role
                        session.access_token = token.access_token
                        session.error = token.error
                    }

                    return session
                },
                async jwt(token, user, account, profile) {
                    if (profile) {
                        token.last_name = profile['custom:last_name']
                        token.first_name = profile['custom:first_name']
                        token.role = profile['custom:role']
                    }

                    if (account) {
                        token.access_token = account.access_token
                        token.accessTokenExpires = Date.now() + account.expires_in * 1000

                        setRefreshCookie({ cookies, refresh_token: account.refresh_token })
                    }

                    if (Date.now() < token.accessTokenExpires) {
                        return token
                    }
                }
            },
            providers: [
                Providers.Cognito({
                    clientId: process.env.COGNITO_CLIENT_ID,
                    clientSecret: process.env.COGNITO_CLIENT_SECRET,
                    domain: publicRuntimeConfig.COGNITO_ENDPOINT,
                    session: {
                        maxAge
                    }
                })
            ]
        })
    )
}


export default Auth

[mtt87]

Out of curiosity how do you refresh the token? Doesn’t seem like you handle it in the code posted here

[digitalhank]

yeah i removed it for brevity. my refreshAccessToken function is quite similar to the docs

[mtt87]

OT have you ever experienced issues with refresh token rotation? We are working on fixing some stuff but would be curious to hear if you ever noticed any issue with your cognito setup
#2071

[digitalhank]

Not yet. My implementation is fairly new so it hasn't been thoroughly tested yet. I can report back if anything unexpected happens.

[indianabenny]

Hi @digitalhank. I'm running into the same issue. Thank you for posting your code example above. I'm new to Next.js. Would you mind posting a quick example of how you are calling Auth in your code? Are you even using the [...nextauth].js with a setup in _app.js or are you handling that in some other manner?

[digitalhank]

@indianabenny the only significant difference between how it's invoked in the docs and my implementation is that I am wrapping the NextAuth function with the Auth function as you can see above.

[dennervidal]

This workaround is pretty neat actually. I've been working with keycloak auth services, and had to apply this in my app to work properly. Only thing I say to you who had the same problem using JWT is to pay attention on session time and cookie expiration (Keycloak is not a default provider, so the management is totally on me). In order to auto refresh the tokens, set the provider options.

I think this should be considered in future versions of next-auth, since not every JWT is short enough to fit in a cookie.

[indianabenny]

See another example here for how this can be solved:
https://stackoverflow.com/a/68181560/16337541

[stale[bot]]

Hi there! It looks like this issue hasn't had any activity for a while. It will be closed if no further activity occurs. If you think your issue is still relevant, feel free to comment on it to keep it open. (Read more at #912) Thanks!

[thetaPC]

This is still an issue.

[thorep]

Im having issues storing refresh token ...if i to a substr and take just part of it , i dont get errors...

[balazsorban44]

This is a browser limitation. A single cookie can only contain 4096 bytes, if you try to set a value that exceeds it, the cookie simply won't be created. To mitigate this, we should introduce cookie chunking for the session cookie, which is not currently in the works. You could try using a database adapter, but understandably that would complicate your setup. Another way is to chunk the cookie yourself, but I only recommend that if you know what you are doing. The jwt callback is the right place for that. Remember if you use refresh_token, you should probably encrypt the JWT as well in addition to the default signing. Encryption might introduce a slight sizing overhead on its own.

[balazsorban44]

Update, cookie chunking is on the way! #3101 🎉

[digitalhank]

lovely to hear!