Is a Refresh Token really necessary when using JWT token authentication?

Question

I'm referencing another SO post that discusses using refresh tokens with JWT.

JWT (JSON Web Token) automatic prolongation of expiration

I have an application with a very common architecture where my clients (web and mobile) talk to a REST API which then talks to a service layer and data layer.

I understand JWT token authentication, but I am a little confused at how I should use refresh tokens.

I want my JWT authentication to have the following properties:

1. JWT Token has an expiration of 2 hours.

2. The token is refreshed every hour by the client.

3. If the user token is not refreshed (user is inactive and the app is not open) and expires, they will need to log in whenever they want to resume.

I see a lot of people claiming to make this a better experience using the concept of a refresh token, however, I don't see the benefit of this. It seems like an added complexity having to manage it.

My questions are the following:

1. If I WERE to use a refresh token, wouldn't it still be beneficial to have a long term expiration for good practice on that token as well?
2. If I WERE to use a refresh token, would that token be persisted with the userId and/or JWT token?
3. When I update my token every 1 hour, how does this work? Will I want to create an endpoint that takes in my JWT token or my refresh token? Will this update the expiration date of my original JWT token, or create a new token?
4. Is there the need for a refresh token given these details? It seems that If the user is just using a JWT token to grab a new token (per the link above) then the refresh token is obsolete.

Bridal

Answer 1

Let me come to your questions a little later down the line and start by actually discussing the whole purpose of a refresh token.

So the situation is:

The user opens the app and provides his login credentials. Now, most probably the app is interacting with a REST backend service. REST is stateless, there isn't a way to authorize access to the APIs. Hence, so far in the discussion, there is no way to check if an authorized user is accessing the APIs or is just some random requests coming through.

Now to be able to solve this problem, we need a way to know that the requests are coming from an authorized user. So, what we did was to introduce something called an access token. So now once the user is authenticated successfully, he is issued an access token. This token is supposed to be a long and highly random token (to ensure that it can not be guessed). This is where the JWT comes into the picture. Now you may/may not want to store any user-specific details in a JWT token. Ideally, you would want to just store very simple, extremely non-sensitive details in the JWT. The manipulation of the JWT hash to retrieve other user's details (IDOR etc.) is taken care of by JWT (the library being used) itself.

So, for now, our problem with authorized access is solved.

Now we talk of an attack scenario. Let's say using all of the above user Alice, using the app, has the authorized access token and now her app can make requests to all the APIs and retrieve the data as per her authorization.

Assume that SOMEHOW Alice loses the Access Token or put another way, an adversary, Bob, gets access to Alice's access token. Now Bob, despite being unauthorized, can make requests to all the APIs that Alice was authorized to.

SOMETHING WE IDEALLY DON'T WANT.

Now the solution to this problem is :

1. Either detect that there is something of this sort happening.
2. Reduce the attack window itself.

Using just the access token alone, it is hard to achieve condition 1 above, because be it Alice or Bob, it's the same authorized token being used and hence requests form the two users are not distinguishable.

So we try achieving 2 above and hence we add an expiration to the validity of the access token, say the access token is valid for 't' (short-lived) time.

How does it help? Well, even if Bob has the access token, he can use it only while it is valid. As soon as it expires, he will have to retrieve it again. Now, of course, you could say that he can get it the same way he got it the first time. But then again there's nothing like 100% security!

The above approach still has a problem and in some cases an unacceptable one. When the access token expires, it would require the user to enter his login credentials and obtain an authorized access token again, which at least in case of mobile apps, is a bad (not acceptable) user experience.

Solution: This is where the refresh token comes in. It is again a random unpredictable token that is also issued to the app along with the access token in the first place. This refresh token is a very long-lived special token, which makes sure that as soon as the access token expires, it requests the server for a new access token, thus removing the need for the user to re-enter his login credentials to retrieve a new authorized access token, once an existing one has expired.

Now you may ask, Bob can have access to the refresh token as well, similar to the way he compromised the access token. YES. He can. However, now it becomes easy to identify such an incidence, which was not possible in the case of an access token alone, and take the necessary action to reduce the damage done.

How?

For every authenticated user (in case of a mobile app, generally), a one to one mapped refresh token and access token pair is issued to the app. So at any given point in time, for a single authenticated user, there will be only one access token corresponding to a refresh token. Now assume that if Bob has compromised the refresh token, he would be using it to generate an access token (because access token is the only thing which is authorized to access resources through the APIs). As soon as Bob (attacker) requests with the newly generated access token because Alice's (genuine user) access token is still valid, the server would see this as an anomaly, because for a single refresh token there can be only one authorized access token at a time. Identifying the anomaly, the server would destroy the refresh token in question and along with it all, it's associated access tokens will also get invalidated. Thus preventing any further access, genuine or malicious, to any authorization requiring resources. The user, Alice, would be required to once again authenticate with her credentials and fetch a valid pair of a refresh and access tokens.

Of course, you could still argue that Bob could once again get access to both refresh and access tokens and repeat the entire story above, potentially leading to a DoS on Alice, the actual genuine customer, but then again there is nothing like 100% security.

Also as a good practice, the refresh token should have an expiry, although a pretty long one.

Vladi

This is a great answer that brings up some questions for me. What possible way could Bob steal the access token if he did not have access to Alice's phone and the token was only sent over HTTPS? You say that "For every authenticated user (in case of a mobile app, generally), a one to one mapped refresh token and access token pair is issued to the app." Does this mean that Alice cannot use the same token on her mobile phone and desktop machine? If so, it would be practically equivalent to Bob using the same token on a different machine, right? – Pin

@Pin many ways an access token can be compromised. 1. Loosing one's device. 2. The app had some vulnerability leaking the token to other apps on the device 3. The underlying OS version itself has holes, may or may not be zero days 4. The user herself sniffing her own traffic (HTTPS won't really help) to get the access token and in absence of absence of an expiry use the token even after say for example, she has been blocked from using the app etc. For the 2nd quest, guess for every new device, the whole authentication flow would be repeated to issue an authorization. Open for discussion. – Vladi

This is a pretty good explanation. I have a question though: does usage of a refresh token still require the client to provide an id/secret? I think I've seen examples where the secret is passed (just as how you would initially authorize yourself) and other examples where only the refresh token is required. If a secret isn't passed, how can the auth server know how to sign a new, valid access token? If a secret is passed though, won't that require some sort of server side processing (database check for instance) to validate the client and secret? – Mccune

Also, in the following scenario: "As soon as Bob (attacker) makes a request with the newly generated access token, because Alice's (genuine user) access token is still valid, the server would see this as an anomaly, because for a single refresh token there can be only one authorized access token at a time", how does the server know that this is an anomaly? Because the existing access token has not expired yet? If so, how is that any different from a legit refresh call before expiry occurs? – Mccune

A logged in user has only one access token and only one refresh token. If an attacker gets the refresh token and creates another access token then the authentication server should detect the existence of two different access tokens for a user and revoke the refresh token and the two access tokens, forcing the user to send again his credentials so as to obtain a new access token and a new refresh token. – Perfection

"because for a single refresh token there can be only one authorized access token at a time. Identifying the anomaly, the server would destroy the refresh token" -- That doesn't sound right. Access Tokens cannot be destroyed, they only expire. Until that time, they are valid and remain client-side. – Salpa

This is a great answer. One note. A gmail user can have multiple refresh-tokens because they can have multiple devices. Though you're absolutely correct. A single refresh token can't be shared across two devices. – Belcher

What if Alice does not login for a while to refresh her access token? Lets say Alice signs off for the night and her access token naturally expires, her refresh token is still valid for days. Couldnt bob use Alice's refresh token in this situation to generate a new access token? Since their isnt a valid access token paired in the DB with the refresh token due to it expiring naturally. I am probably understanding the last check wrong, but it sounds like the only way to see if someone got your refresh token is to check if there is ONLY a valid access token at the time the request it made. – Tibiotarsus

great answer! one question is, for access token and refresh token, if one is stolen, then another must be stolen too, right? – Ginnie

Great answer, but if you allow for multiple device access, the refresh token anomaly listed above isn't valid. – Beautifully

Does the server has to maintain a state for refresh token to find the anomaly? If yes then using a refresh token is not stateless implementation. Is that a current assumption? – Cogitation

@Tibiotarsus I believe this is a reason why you should create a new refresh token every time you create a new access token. In this case, if Alice logs in after the Bob's access token expires the server will know that her access token was possibly compromised because it is not present in the db and it should invalidate all access and refresh tokens for this user. Nevertheless, Bob was able to use this key to gain unauthorized access. See this link – Bowery

Good answer with some flaws. " Identifying the anomaly, the server would destroy the refresh token in question and along with it all, it's associated access tokens will also get invalidated". This doesn't happen automatically. Invalidating refresh token doesn't mean access tokens will get destroyed. Access token will be invalidated after their expiry. " because for a single refresh token there can be only one authorized access token at a time" One can request for more access tokens preemptively before its expiry. So this doesn't look correct. – Galinagalindo

As far as the anomaly is concerned , i think a single refresh token is strictly bound to a specific token not the account , so probably we can have multiple refresh tokens active against a single account \ – Stenography

If you count usage of the refresh token as security incident and propose to destroy the tokens - how does one accomplish the one thing that the refresh token was meant to do? which is refresh the jwt token. Say a user is nearing the expiry of the jwt token and wants to renew it -- we would cause them to logout with this logic. Second - are you saving all your JWT tokens and querying them on every call? how else would you track a one to one mapping of tokens? - that is definitely an anti-pattern. – Taillight

@Galinagalindo To make it even more challenging, how many refresh tokens should we have? Ideally, only one! Each time when a user logs in or refreshes tokens, new tokens should be issued and all previous refresh tokens should be deleted. Why? If an attacker steals a refresh token, they can issue a brand new refresh token and our user will not be able to invalidate it (they have 0 infos about it). By invalidating all active refresh tokens when issuing a new one, a user will be forced to login again, thus invalidating attackers refresh token. The user that knows login credentials, wins in the end. – Biddick

@Galinagalindo To continue, a single refresh token per user has a drawback too - a single user session per all clients. It means that a user cannot be logged in in both browser and mobile app at the same time. – Biddick

Once both (JWT token, refresh token) are stolen, there is no way to distinguish Alice from Bob. At that point, everything you care about is token invalidation, e.g. JWT blacklisting. So I see no benefit of using 2 tokens versus a single long-lived JWT token with invalidation capability. – Skewer

Also, refresh tokens are only valid after the access token has expired. So they can and should not be overlapping in terms of timespan – Sapient

@Vladi I have a post here discussing if we really need refresh tokens that you might be interested in security.stackexchange.com/questions/274267/… – Lotz

@Skewer i agree, if we're implementing refresh tokens, we're going stateful, why not just have a JWT white list! – Node

Answer 2

I believe for this scenario you could work with the access token alone, making life easier for your clients but keeping the security benefits of a refresh token.

This is how it would work:

1. When your user logs in with credentials (username/password) you return a short-lived JWT. You also create a db record where you store:

   • JWT id
   • user id
   • IP address
   • user agent
   • a valid flag (defaults to TRUE)
   • createdAt
   • updatedAt

2. Your client submits the JWT in every request. As long as the JWT hasn't expired, it has access to the resources. If the JWT expired, you refresh it behind the scenes and return both the resource and an additional X-JWT header with the new JWT.

3. When the client receives a response with an X-JWT header, it discards the old JWT and uses the new one for future requests.

How refreshing the JWT works on the server

1. Look for the matching db record using the JWT id.
2. Check if the valid flag is still true, otherwise reject.
3. Optionally, you can compare the request IP address and user agent against the stored IP address and user agent, and decide to reject if something looks fishy.
4. Optionally, you can check the db record's createdAt or updatedAt fields, and decide not to refresh if too much time has passed.
5. Update the updatedAt field in the db record.
6. Return the new JWT (which is basically a copy of the expired JWT, but with an extended expiration time).

This design would also give you the option to revoke all tokens for a user (for example, if the user loses his phone or updates his password).

Benefits:

• Your client never has to check expiration times or make refresh token requests, all it does is check for an X-JWT header on responses.
• You can add custom refresh logic based on IP address, user agent, max-token age, or a combination of those.
• You can revoke some or all tokens for a user.

Agincourt

Side note: if we're making CORS requests, the custom X-JWT header won't be available. – Dipole

@Dipole If you want to expose the custom X-JWT header on CORS, you'll need to include it on the Access-Control-Expose-Headers header. Another option is to include it in the response body as meta-data. – Agincourt

Why Return the new JWT (which is basically a copy of the expired JWT? Is not the whole point of it to change token, to give user new one? – Footpoundal

@Agincourt Why Return the new JWT (which is basically a copy of the expired JWT ? Is not the whole point of it to change token, to give user new one? – Footpoundal

Answer 3

If I WERE to use a refresh token, wouldn't it still be beneficial to have a long term expiration for good practice on that token as well?

Refresh Tokens are long-lived, Access Tokens are short-lived.

If I WERE to use a refresh token, would that token be persisted with the userId and/or JWT token?

It would be persisted as a separate token on the client, alongside JWT but not inside JWT. UserID/UID can be stored inside the JWT token itself.

When I update my token every 1 hour, how does this work? Will I want to create an endpoint that takes in my JWT token or my refresh token? Will this update the expiration date of my original JWT token, or create a new token?

Yes, you need a separate service that issues and refreshes token. It won't update the expiration of the existing JWT Token. A token is simply JSON field-value pairs that are base64 encoded. So changing the data, changes the output. The token also has the issue date, which will at the very least change on every fresh issue (refresh). So every token will be unique and new. The old tokens will auto-expire, hence you need expiration on all Access Tokens, otherwise they will linger around forever.

The other answer here states that old tokens get destroyed when you issue a new token. That's simply not the case. Tokens cannot be destroyed. In fact, you can harvest hundreds of tokens by constantly contacting the auth server and asking for new fresh tokens using your Refresh Token. Each of those Access Tokens will be valid till their expiry. So expiry is imperative, and it should be short.

Is there really the need for a refresh token given these details? It seems that If the user is just using a JWT token to grab a new token (per the link above) then the refresh token is obsolete.

JWT tokens have client claims. For example is_manager:true claim on a JWT token might allow access to manager-level features. Now if you decide to demote the user from manager to contractor, that won't take effect immediately. The user may still be using the old token. Finally when that expires, he hits the auth server to refresh his token. The auth server issues a new token without the managerial claim and the user won't be able to access managerial features any more. This creates a window during which the user's claims are not in sync with the server. This again explains why Access Tokens should be short-lived so sync'ing can happen often.

Essentially you are updating the authorization checks every 15 minutes, instead of checking them on every single request (which is how typical session-based auth works). If you want real-time permissions instead of every-15-minute refreshes, then JWT may not be a good fit.

Salpa

"Tokens cannot be destroyed.". THANK YOU. I cannot believe the other answer got so many votes. . . The whole point of JWTs is that you don't need a database to check which ones are valid or not. It should be stateless . . – Coletta

Actually, I'd implement double-checking for admin access. If isManager is true, it just means to check the database for manager-access. If the flag is false, the user is immediately denied the resource. – Beautifully

You can do a hybrid approach where you have a list of 'not-expired-but-invalid' tokens saved in memory (if your app has a small number of users). The actual 'not-expired-but-invalid' tokens are saved in redis with a TTL of their expiry -- they are refreshed from redis in the background every second -- this way you can also give users a logout functionality. – Taillight

While it is true that you don't need a central database for your tokens, you can effectively invalidate tokens by updating the secret used to create them. This is a good idea, say when a user updates their credentials, or invalidates a device. – Mcbroom

@Coletta agreed, the others answers explicitly hinting at the fact that we're storing and checking the db aganist incoming tokens on every request, it kind of defeats the purpose – Node

Answer 4

Depends on scenario

Anatomy of a JWT

---

• Should contain non-sensitive information
• Should have a timespan
• Should have a unique key

NOTE One thing you need to always keep in mind about JWTs is that there is always going to be a trade off between security, convenience, and performance (negligible in some cases).

Stateful (Security) vs Stateless (Convenience and Performance)

Stateful tokens

You want to maintain a state about your tokens in case they get leaked or end up in the wrong hands. There are different want to keep the state of the tokens.

• White List: Store the token id jwt.kid in the database or cache system like Redis or memcached, with an auto-eviction time setting. Each time you receive a request, you validate the token, and then check the storage for the corresponding jwt.kid value. If not found, reject the request. This gives you greater control over the token. You could revoke tokens at any point in time by removing it from the storage. But as you can see, you may incur overhead when visiting your storage on each request.

• Black List: Store the token id,s forever in some persistent storage, and if the token id is found there, reject the token.

Stateless tokens

Not maintaining any state means that anyone with the token can make authenticated requests. You could not revoke stateless tokens. Your only hope is the time expiration.

Authentication Flow

---

Single Token: Access token

Can be long-lived or short lived depending on use case. Once expired or revoked, authentication with credentials is required.

Multiple Tokens: Access and Refresh token

Combining an access token and an extra token, this combination really is for user experience. What happens here is that the access token is short lived and can be used to perform various requests. The refresh token is only valid at the time after the access token has expired, with itself also having an expiration period. The time constraint prevents the use of the refresh token from potentially destroying the counterpart access token by requesting a new token pair. The refresh token cannot be used to do anything else other than request for a new access token, which in turn returns a new pair of access+refresh tokens, effectively decommissioning the refresh token that made the request.

So even after both tokens leaked, only the access token would be considered valid until it were revoked or expired. The refresh token would only be valid if the access token expired naturally and withing its own usage period.

Sapient