I got Auth0 going to log my users in and out. However I am currently testing on what happens when the access token expires. Currently I only get this error:
What now? Should I redirect to login in getServersideProps()? Should I enable refresh tokens, if so, how? Anyone got any guidance? Would gladly appreciate any help. I got to admit, the documentation on that topic is extremely sparse and has lots of potential for improvement.
Hi @amg1,
I can’t help with the specific next.js issue, but I suggest you ensure refresh token support is enabled before using the offline_access scope.
Please, go to your NestJS API in the Auth0 dashboard and enable refresh token support through the Allow Offline Access toggle button
I also suggest enabling refresh token rotation to improve security (Auth0 dashboard → your App → Refresh Token Rotation section).
Check out this article to learn more about refresh tokens.
I’m reopening this issue, as I don’t think it was fully answered.
I’m facing the same scenario, and yes enabling the offline_access would work, but just partially (and that, assuming I wanted to enable the refresh_token at all). Here are my points:
Let’s say I don’t want to turn offline_access on. In this scenario, I would expect the nextjs-auth0 library to automatically logout the user (or clear the session) and redirect it to the /login page. Otherwise, the library forces us to put a try/catch block in every place we use getAccessToken and to deal with the redirections and session flush.
Alternatively, I would enable the usage of refresh_token. However, if at some point this token expires too, we will run into the same situation.
So my question here is: does the library offer a fallback handler (or similar) to redirect the user to the /login page in these cases?
Also facing this issue and the update @paleloser gave is spot on for why this might be such an important thing to fix.
Essentially all of my decision making about using and implementing @auth0/nextjs-auth0 came down to the ease around login/logout flows and not needing to add such checks all over the place. I would have assumed this kind of detail would be handled automatically — and it has me further concerned now because I ran into this after a fresh reload of the app after a night of not working, and my user seems logged in just fine until I ran into this, which makes me think that the token being expired didnt trigger logout on that fresh reload either.
Running into the same issue. Any change somebody could recommend a solution or at least a workaround? I really would like to avoid try … catch block to every method calling an api endpoint. Maybe it is possible to do it with some middleware, but it would be great to learn about what is the official recommendation from Auth0.
Hey @kenkoooo-estie,
I can’t help with Next.js specifically, but in general what you need to work with refresh tokens is what I pointed out here.
I’m not sure how this works in the Next.js SDK, but generally speaking, there is no relationship between the access token expiration and the user session expiration. In other words, you can’t expect that your user session automatically expires when your access token expires. In fact, an access token can be used even when a user is not logged in. Think of your git client that uses your GitHub personal access token to push your changes even if you don’t have an active GitHub user session.
I would need a bit more of background information about your specific cases and how you are building and calling your API routes.
The SDK won’t redirect when you call the getAccessToken or getSession token because there are scenarios where you want to check on those without having to redirect.
If you want to cause a redirection you can either use a middleware validation, or withApiAuthRequired on each API route, no need for a try/catch, though you’ll have to add that wrapper to each API route.
Protecting an API with withApiAuthRequired will cause the API to return a 401, and you’ll have to handle the redirection on the client side.
If you rely solely on Server Components to read and update your session you should be aware of the following:
If you have a rolling session (the default for this SDK), the expiry will not be updated when the user visits your site. So the session may expire sooner than you would expect (you can use withMiddlewareAuthRequired to mitigate this).
If you refresh the access token, the new access token will not be persisted in the session. So subsequent attempts to get an access token will always result in refreshing the expired access token in the session.
If you make any other updates to the session, they will not be persisted between requests.
Thanks @merton , and welcome to the Auth0 community.
If you are using the new App Router, it is true, that cookies can’t be updated on server components, this was a design decision by the Next.js team. However, there’s a few options to overcome that challenge, but it will depend on the characteristics of your application.
For instance, you can use server actions, or API routes to refresh the token, however, depending on the nature of your application, it may not be a good fit.
Another possibility is to do it in middleware, though, it may add some unnecessary checks on the middleware, and you’ll have to balance that out for your application.
Alternatively, the Auth0 SDK allows you to use your own session store, by default it saves the session in cookies, but you could opt to build your own session store, store in cookies only a session id, and then store the token information in something like Redis.
