Stytch allows you to switch between using JWTs and session tokens as needed.
Using session JWTs
A session JWT is a signed token that can be locally verified.
- Contains standard claims and information about the underlying session.
- Expires after 5 minutes, but can be refreshed via API for the duration of the underlying session.
- Will locally validate during the 5-minute period, even if the underlying session is revoked.
Reasons to use JWTs
- Reduce latency with JWTs
Speed up authorization requests without a call to the database.
- Add custom claims
Encode additional information into your Stytch session JWTs.
- Authorize external applications
Leverage identity information and authorization granted through the JWT.
Using session tokens
A session token is an opaque token that must be verified via an API call.
- Does not contain information about the member or the underlying session.
- Invalid once the underlying Session object is revoked or expires.
Reasons to use session tokens
- Added security layer
Ensure every call is authorized at that exact moment.
- Storage limitations
Access to user-side storage is limited and can only store small values.
- Limit session exposure
If you don’t want to expose session data or metadata in user storage (e.g. authentication factors or timestamps).