I've been reading about this for a while, and nothing makes sense, and the explanations are conflicting, and the comments are proving that.

So far what I understood is that JWTs are storing information encoded by the server, can have expiry times, and the server with its secret key can decode the information in it if it's valid. Makes sense.

It is useful for scalability, so independent APIs can decode, and validate the information in the token, as long as they have the secret key. Also, there's no need for the information to be stored in any database, not like in sessions. Makes sense.

If the token gets stolen, the API has no way to tell if the token is used by the right person, or not. It is the downside of the above.

By reducing the expiry time of a token, the security vulnerability can be reduced, so thieves have less time to use the tokens without permission. (side question, but if they were able to steal it once, they will probably do it second time as well)

But reducing the time of how long the token is valid means that the user will need to log in every time the token expires, and as from above, it's quite frequent, so wouldn't provide too good UX. Makes sense.

From now, nothing makes sense:

Introducing a refresh token would solve this problem, because it has a longer expiry time. With the refresh token access tokens can be generated, so the user can be logged in as long as they have the refresh token - which is for a longer period of time -, while a stolen access token is still only valid for a short time.

For me the above seems like an extra layer of complexity without any improvement in security. I.e. for me it seems like the above equals to a long-living access token.

Why? Because for me it seems the refresh token is basically an access token (because that's what it generates). So having the refresh token means unlimited access tokens, so unlimited access to the API.

Then I have a read an answer that there's a one-to-one mapping of refresh token, and access token, so stealing the access token still means unauthorised access to the API, but only for a short time, and stealing the refresh token would generate a different access token, so the API could detect the anomaly (different access tokens are used for the same account), invalidating the access tokens.

It seems like I'm not the only one who's confused about the question.

If the above is not true, how refresh tokens really help?

If the above is true, and there really is one-to-one mapping of refresh tokens, and access tokens:

• it completely loses it's benefit of being "stateless"
• the user cannot be logged in from multiple devices (it would have been an "anomaly")
• I can't understand how an access token could be invalidated - is there a session ID stored in the token data, or the user is "blocked"?

It would have been really great if someone could clear the question, because from 5 explanations, 5 conflicting statements are (sometimes the same explanation contains conflicting information), and many developers want to understand this method.

CodePudding user response：

There is this general confusion around token-based auth, so let's try to clear some of it up.

First, JWTs are not just "encoded" by the server, they are "signed" (which more precisely is message authentication usually). The purpose is that such a token can not be altered or changed by the client, any field (claim) in the token can be trusted to be as the issuer created it, otherwise validation will fail.

This yields two important takeaways:

• validating tokens is important (obviously) in any implementation
• the contents (claims) of a JWT are not encrypted, ie. it's not a secret and can be viewed by the client

Such a token can be used to maintain a session without server-side state, if it contains some kind of an identity for the subject (user, like a user id or email address), and an expiry.

Another important takeaway though:

• Logout (immediate session invalidation) is not possible in a stateless way, which is a drawback. To be able to log out as in invalidate an existing session, the server must store and check revoked tokens, which is necessarily a stateful operation.

Also a JWT token is typically stored in a way that it's accessible for client-side code (javascript), so things like who the user is and when the token will expire can be read by the client app. It need not be so, yet most implementations do this, eg. store it in localstorage. This makes these tokens susceptible to XSS attacks, meaning that any successful XSS will be able to get the token.

For the reasons discussed so far, JWT authentication is inherently less secure than a plain old session, and should only be used if there is a need. Many times when token auth is used, it is not actually necessary, just fancy.

Sometimes such a token is stored in a httpOnly cookie, but in that case the token cannot be sent to multiple origins (one benefit of localStorage) and a plain old session id could also have been used, and would actually be more secure.

Ok, so what are refresh tokens. As you correctly stated, limiting the lifetime of an access token is useful to limit the validity of a compromised token. So a refresh token can be used to get a new access token when the old one expired. The key is where these are stored.

A key takeaway:

• If a refresh token is stored the same way as the access token, it usually doesn't make any sense. This is a common mistake in implementations.

In a better architecture, the following can happen:

• There are (both logically and "physically" as much as it makes sense in today's cloud world) at least two separate components: the identity provider (IdP, or "login service"), and the resource server (eg. an API).
• When a user logs in, they actually create a session with the IdP. In this case either a plain old session id (acting as refresh token) or an actual JWT refresh token is set up for the IdP origin (domain name).
• An access token is then created when needed for the resource server origin, using the existing session with the identity provider.
• Now even if there is a total compromise of the resource server, like in case of successful XSS, the refresh token belongs to a completely separate origin, so cannot be accessed by the attacker. Even if it's the same origin, but the refresh token is in a httpOnly cookie, that helps, because the attacker then needs to be able to perform repeated XSS against a victim user to receive new access tokens.

There can be implementation variants of this, but the point is the above, separation of access to the two tokens.

A one-to-one mapping of refresh tokens to access tokens as you described would I think be unusual and also unnecessary, but one session per user is in fact sometimes a requirement (especially in financial applications where you want to have a very clear audit trail of what a user did). But this is not much related to the things discussed above.

Also as stated above, proper logout (session invalidation) is not possible in a stateless way. Fortunately, very few applications actually need to be truly stateless on the server-side.