Hello,
I am using stytchClient.session.authenticate({session_duration_minutes: 60});
from the @stytch/nextjs library and the response seems to change the expiration of the session but it doesnt issue a new session token or jwt token. Should it be issuing a new jwt with the new expiration?
Hey Blane,
Thanks for posting!
the response seems to change the expiration of the session but it doesnt issue a new session token or jwt token. Should it be issuing a new jwt with the new expiration?
That’s correct - calling
stytchClient.session.authenticate({ session_duration_minutes: 60, });
will extend the duration of the existing session stored by the SDK by 60 minutes, rather than generating a new Session.
For some additional context on session management, session JWTs always have a lifetime of 5 minutes, regardless of the underlying session duration. Our JS SDKs (include NextJS) automatically refresh the session JWT in the background every few minutes (as long as the underlying session is still valid), which keeps the JWT fresh.
We do this for two main reasons:
- Because session JWTs can’t be revoked once they are minted, setting them to expire every 5 minutes limits the window where a lifted JWT could be used as an attack vector.
- Authenticating a JWT on your backend has much lower latency than authenticating a session token. This is because JWTs can be validated locally, while session tokens need to contact Stytch servers to be validated. By keeping the JWT fresh, the JS SDK offers the option to validate JWTs locally on your backend (for instance, calling our
authenticateJwt()
method in our Node SDK) rather than authenticating a session token via making a request to Stytch servers (for instance, by calling our authenticate()
method in our Node SDK).
You can read a bit more about session tokens vs JWTs in our blog post here: JWTs vs. sessions: which authentication approach is right for you? - Stytch!
Sessions can be revoked via the session.revoke()
method, which is used to log a user out of your application.
The session duration set when minting a new Stytch Session can be extended as mentioned above, and as long as that session is still valid (e.g. not expired or revoked), our JS SDKs will automatically refresh the JWT in the background.
hey Matt thank you for the quick and thorough reply. That is helpful information. We are using Hasura on our backend and are leveraging their jwt auth which uses stytch’s jwk endpoints. When you say the NextJS SDK automatically refreshes the session jwt every few minutes, how can I see the details for that? Does it only happen on the server side or on the client side? I am polling my session and I am not seeing the session_jwt updating at all in those responses. What does in the background mean and where is the code that is responsible for doing that jwt refresh? Thank you!
Hey Blane,
Of course, happy to help!
When you say the NextJS SDK automatically refreshes the session jwt every few minutes, how can I see the details for that?
…
What does in the background mean and where is the code that is responsible for doing that jwt refresh?
Our frontend JS SDKs automatically call session.authenticate()
every few minutes to refresh the JWT. These calls are made in the background via the bundled SDK code (from your frontend browser where the SDK is initialized), so you won’t necessarily see the calls themselves being made.
I am polling my session and I am not seeing the session_jwt updating at all in those responses.
The background refresh process updates the session_jwt
value stored in cookies on the frontend. This session cookie is automatically included in requests made to your backend (as long as they share a domain), so I’d expect the session_jwt
value to be updated on the frontend cookies, as well as in any subsequent requests made to your backend after a refresh. You can read a bit more about session management with our frontend JS SDKs here: https://stytch.com/docs/sdks/javascript-sdk/resources/cookies-and-session-management.
It sounds like you may be using our NextJS SDK on the frontend, along with a Hasura backend. Can you clarify what you mean by polling the session, and where this is taking place?
The refresh flow generally looks something like this (occurring every few minutes):
- The frontend JS SDK refreshes the JWT by calling
session.authenticate()
in the background, generating a new JWT.
- The SDK automatically updates the
session_jwt
cookie stored on your frontend with this new JWT value.
- Requests to your backend will include the new
session_jwt
value (as long as your backend shares a domain with your frontend), and can be validated using the JWKS endpoint since the JWT is not expired.
Got it, so I wont see these calls on the network tab of my browser?
Heya Blane,
Got it, so I wont see these calls on the network tab of my browser?
You will see these calls in your browser’s network tab, I’ll include a screenshot of what that looks like below. I used one of our demo apps and you can do the same thing by logging in and then watching the network tab for ~3-4 minutes.
Those calls are automatic and don’t require any code on your end, they serve to heartbeat the session and refresh the shorter lived JWT when its about to expire (while the underlying session length is still valid).
Let us know if you have any other questions!
Thanks Chris - I appreciate your responsiveness and patience with me, I am making progress debugging this. I can confirm I am seeing the authenticate request every 3-4 minutes on the client side and a new session_jwt being issued. I identified my issue being that it seems the session_jwt I get from this code is the original jwt and is stale/not being updated every 4 minutes,
import { useStytch } from '@stytch/nextjs';
const { session } = useStytch();
const token = session.getTokens()?.session_jwt;
Hey im going to close this for now, thanks
Hey Blane – sounds good! Glad to hear you identified the issue.
Please let us know if anything else comes up, and we’ll be happy to help!