I recently came across an interesting article that discusses the pros and cons of using refresh tokens. A comment suggested that instead of using a refresh token to get new access tokens, we could simply validate the existing access token. If it has expired but isn't blacklisted, we could issue a new one using that expired token. This got me thinking: why do we need refresh tokens at all if this approach could work just as effectively, maintaining the same security levels and database check frequency?
5 Answers
That comment makes a good point for specific scenarios, but generally speaking, using refresh tokens is still a best practice. They are part of many authentication standards for good reason. If your system is designed for long-lived tokens, you might not need them, but for most applications, refresh tokens help ensure security and manageability.
What you're suggesting complicates things by removing the stateless nature of JWTs. Every time an access token is used, you'd have to verify its validity against the auth service. This can slow down performance significantly and would add more complexity to the system.
The original intent of JWTs was for distributed systems where the authentication server and services are separate. If an access token needs to be blacklisted, it means additional checks would be necessary for each request, which defeats the purpose of quick verification. Refresh tokens help manage this balance more efficiently.
For those who might find this thread helpful, consider using opaque tokens or httpOnly cookies for session management. They're usually easier to handle than juggling refresh tokens and blacklists. JWTs are fantastic but might not fit every use case, especially for simpler projects.
The main benefit of refresh tokens is that they're used only once for security purposes. Once a refresh token is used, it gets invalidated, making it much harder for anyone who might intercept it to gain access. In contrast, using an expired access token is risky since if someone has intercepted that token, they could potentially use it before you invalidate it.
That's a valid point! Plus, the refresh token should ideally be stored in a secure backend, so your application shouldn't have direct access to it. This setup provides an extra layer of protection against attacks like XSS, as any captured token would only be valid for a limited time.
Exactly! A JWT should be able to function without constant checks, and keeping it solely as a means of trust for a limited time is more efficient.