Comment by kevincox
2 days ago
This is really just an optimization. It means that you don't need to do an expiry check on the regular token, only on the refresh token. It doesn't change the fact that you should be able to revoke a session before it naturally expires.
Having a short session expiry is a workaround for not being able to revoke a token in real time. This is really the fault of stateless auth protocols (like OAuth) which do offline authentication by design. This allows authentication to scale in federated identity contexts.
OAuth2 is not inherently stateless.
Good call. I said OAuth but what I meant was OIDC and specifically JWT. OAuth (not OIDC) implementations MAY use opaque access tokens that require server side state to validate.
1 reply →
Yeah but depending on how you set it up, you could have a very short expiry. If your auth system is as simple as: Verify refresh token -> Check a fast datastore to see if revoked -> Generate new auth token, this is very easy to scale and and you could have millions of users refreshing with high regularity (<10s) at low cost, without impacting on your actual services (who can verify the auth token offline).
Say you had 1,000,000 users, and they checked every ten seconds, that's 100,000 requests per-second. If you have 1,000,000 users and can't afford to run a redis/api that can handle an O(1) lookup with decode/sign that can handle that level of traffic, you have operational issues ;)
It's all a tradeoff. Yes, it means some user may have a valid token for ten more seconds than they should, but this should be factored into how you manage risk and trust in your org.