Excellent breakdown of when stateless JWT architectrure makes sense versus session-based approaches. The access/refresh token pattern you describe solves a real problem: most systems need the horizontal scalability of stateless tokens but can't tolerate the security risk of long-lived access tokens. What's less obvous is the token revocation challenge with JWTs. Once issued, they're valid until expiry even if you need to immediately revoke access. Some teams maintian revocation lists, which reintroduces statefulness, while others accept the risk window between revocation events and token expiry.
I don’t think use OAuth2 is best practice for login via IdP. It can be twisted by impersonating. The derived from OAuth2 is more safe for authentication
great post.
“We still need to decide what they’re allowed to do — and that’s Authorization, which we’ll cover in the next post.”
a distinction too often missed by newer security folks. great highlight.
Nice breakdown. Funny how auth feels “basic” on paper but ends up shaping half your system in real life 😅
Solid refresher, thanks!
Excellent breakdown of when stateless JWT architectrure makes sense versus session-based approaches. The access/refresh token pattern you describe solves a real problem: most systems need the horizontal scalability of stateless tokens but can't tolerate the security risk of long-lived access tokens. What's less obvous is the token revocation challenge with JWTs. Once issued, they're valid until expiry even if you need to immediately revoke access. Some teams maintian revocation lists, which reintroduces statefulness, while others accept the risk window between revocation events and token expiry.
thank you for your valuable comment
thanks you
What do you mean by Bearer token being stateless? Since server looks up for a token in a DB/Cache, would it not be considered staeful?
I don’t think use OAuth2 is best practice for login via IdP. It can be twisted by impersonating. The derived from OAuth2 is more safe for authentication