I definitely don’t understand why we even need to refresh JWT if we don’t have an refresh token on the client side, if the JWT token is compromised, a potential attacker will just access my JWT refresh endpoint from time to time
Hey Klim – thanks for posting!
The main benefit of using JWTs in the context of Stytch session management is a significant reduction in session authentication latency when the JWTs are validated locally.
When using session tokens, your application must communicate with the Stytch API during every session authentication call – and for certain applications, the additional latency added by these calls is undesirable. When using JWTs instead of session tokens, the JWT validation can occur locally as long as the JWT is unexpired, which avoids that extra latency caused by communicating with the Stytch API.
The 5 minute expiration of our JWTs is a security measure that requires your application to communicate with the Stytch API at least once every 5 minutes to check the validity of the underlying Stytch session, in order to make sure that the session hasn’t been explicitly revoked. This essentially limits the amount of time where your application could continue successfully validating the JWT locally even after the underlying session has been revoked.
That said, Stytch JWTs are as sensitive as session tokens (for the reason you mentioned), and should be treated as such.
We discuss this in more detail in our JWT vs. session tokens blog post, which I think you may find helpful as well: https://stytch.com/blog/jwts-vs-sessions-which-is-right-for-you/
Please let me know if you have any additional questions about this, and I’ll be happy to help!
But what if an attacker steals the JWT and makes requests until the user explicitly revokes the session . In oauth2 openidconnect this is just a little mitigated by refresh token . If an attacker hijacks JWT it will be meaningless because JWT is updated with refresh token. What exactly in stytch protects against this?
I mean, the attacker will just refresh his stolen JWT every time
That’s correct – Stytch JWTs have largely the same security implications as session tokens in that sense. If they’re compromised by an attacker, the attacker will presumably be able to access the user’s account until the session is revoked or expires. You can control the duration of underlying Stytch sessions by setting the session_duration_minutes parameter when authenticating the user, and generally, shorter session durations are more secure.
I’ll note that session management using session tokens/ JWTs is conceptually different than OAuth, and both strategies have their benefits/ tradeoffs. We use session tokens + JWTs to power our session management functionality, rather than OAuth, and the session JWTs that we mint are not intended to be a replacement for OAuth refresh/ access tokens.
Happy to help if you have any additional questions about this!