Session tokens vs. JWTs

• These are considered opaque because they don't contain any information about the Member or the underlying Session.

• The session_token should be authenticated via the SessionsAuthenticate endpoint before a Member takes any action that requires authentication.
• The session_token will be considered invalid if the underlying Session is revoked.

You might use session tokens if...

• Your security needs require that your app must never accidentally use a revoked Session (i.e. even the small 5 minute grace period of our default JWTs is not acceptable to your app's security).

• Your access to user-side storage is limited and can only store small values.

• You don't want to expose the Session data (authentication factors) or metadata (timestamps) in user storage.

• Contains standard claims as well as information about the Stytch Session.

• JWTs can be authenticated locally without an API call. A session_jwt is signed by project-specific keys stored by Stytch. You can retrieve your project's public keyset via our Get JWKS endpoint.
• Expires after 5 minutes but can be refreshed via our Authenticate Session endpoint for the duration of the underlying Stytch Session.
• The session_jwt will successfully locally validate until the five-minute expiration mark, even if the underlying session is revoked. You can always refresh more frequently than that if you prefer.

You might use JWTs if...

• Your application would benefit from the performance improvements of validating user sessions without an external network request.

• You're using Stytch Sessions to authorize actions outside of your app and that authorization works via JWT.

• We strongly recommend that you use our Backend SDKs (available in Node, Python, Ruby, and Go) if you are using JWTs. Our libraries handle the logic to authenticate JWTs locally and automatically fall back to the Stytch API when the JWT is expired.