Related
I have been searching lately about refresh tokens and access tokens with rotation and something hit me.
Why not just use one token instead of access token and refresh token? Include in that token payload (claims) a validation date, and make the validation period very low ( just like access tokens ) and the expiration date very high ( just like refresh tokens ).
If the validation date exceeds the date on the server but did not expired, the server issues a new token and invalidate the old one ( by whatever mean like a blacklist of tokens etc just like when AT expires and new ones are issued using Refresh token) , and if the token expires then the server simply reject the request and ask for authorization ( just like when refresh tokens expires ).
If this approach works then why do we use 2 tokens which makes the dev process harder ?
I think you are forgetting something.
Refresh tokens are stored on the server. Access tokens are not. Access tokens are self contained. This is why they are referred to as bearer tokens. The bearer of the token is granted access.
Which means if an access token is stolen by a malicious party, they can be used as long it has not expired. Access tokens are considers safe because of their limited life span.
In order to use a refresh token in order to request a new access token. You need to have the client id, client secrete that was used to cerate it. You also need to be able to listen to one of the valid redirect uri's for the refresh token response.
Most of APIs around the web provide two methods:
login: given credentials, returns the access_token and the refresh_token
refreshToken: given refresh_token, returns another access_token and a new refres_token.
My question is: why is so widely preferred to do login and then a possible sequence of periodic refreshToken instead of simply login again when access token expires?
Which are the benefits of a refresh versus a full login?
After doing some more research, I find that it's to limit the space for a Man-In-The-Middle attack.
If someone intercept your user/password you have lost. And if you send it in plain at each call, the probability will increase that someone intercept them.
If you login and then for a while use access_token , a bad actor could intercept the access_token, but at least it willl use it until it will expire.
Again, instead of relogin, remote server will use the refresh_token to obtain a new access token.
the refresh token expire after first use so it's useless to intercept.
And so on.
So for server to server, the actually best practice is
login
- receiving access_token and refresh_token
when access_token expire, use refresh_token to obtain a new access_token.
If both access_token and refresh_token expired, relogin with app_id/app_secret pair
I'm looking to employ token-based authentication for a mobile app that keeps the user logged in as long as they have not logged out. My approach is to create a JWT refresh token when the user logs in/signs up; This token never expires, and continues to refresh 20 minute access tokens.
The problem arises when they log out. I've read the best way to go about this is to blacklist the JWT on Redis to store revoked keys. However, since the JWT never expires, the record can never be removed from Redis and can start to chunk a lot of my memory.
Should I be worried about this, or is Redis memory-efficient on this respect? Is there a better way to revoke JWT with no expiration?
A JWT token is a self contained token. That means that it lives on its own until it expires and can't be revoked. So by definition it must expire. Because when it falls into the wrong hands, it'll give access to your resources without being able to revoke it. So yes, you should be worried with this implementation.
The problem here is that you trust the refresh token itself, because it's a JWT. You should in fact trust the server. Not because the JWT can't be trusted, but because the refresh token doesn't have to be a JWT.
Save refresh tokens in memory including the expiration time. You can remove expired tokens from memory. This means that only tokens that exist in memory can be used to request a new access token. And to be on the safe side, use one-time only refresh tokens.
The flow would be something like this:
the user logs in, receives a JWT access token (5 minutes) and the refresh token 1 code (48 hours). Refresh token 1 is saved on the server.
five minutes later: the access token expires
a new access token is requested using refresh token 1.
user receives a new access token (5 minutes) AND the refresh token 2 code (48 hours). Token 1 is removed from memory and token 2 is added to memory.
and this goes on for several hours.
For two days the user doesn't use the app
50 hours later: because both tokens are expired, the user has to login again. Resetting the flow.
On logout remove the refresh token from memory. And if in the meantime you wish to revoke access. Simply remove the refresh token from memory. Within 5 minutes the user has to login again.
JWT also needs to be revoked as best practice.
Yes, JWTs are self tokens and expirations already part of themselves.
But if user logs out and still their JWTs are not expired means someone can use that token to call different APIs. So it is a security breach.
To avoid such things we should maintain JTI claim of that JWT in our backend with the same TTL with the value of JWT "exp".
When the user logs out we have to clear those JTIs and notifcy the API callers about this just putting into some event service from their API Gateways should get to be notified and clear their side cached tokens if anything and cross check with identity system (Introspection).
This is we have to design the system to avoid further security related issues.
I have a program that integrates with the YouTube Live Streaming API. It runs on timers, so its been relatively easy for me to program in to fetch a new Access Token every 50 minutes with a Refresh Token. My question is, why?
When I authenticated with YouTube, it gave me a Refresh Token. I then use this refresh token to get a new Access Token about once an hour. If I have the Refresh Token, I can ALWAYS use this to get a new Access Token, since it never expires. So I don't see how this is any more secure than just giving me an Access Token from the start and not bothering with the whole Refresh Token system.
Basically, refresh tokens are used to get new access token.
To clearly differentiate these two tokens and avoid getting mixed up, here are their functions given in The OAuth 2.0 Authorization Framework:
Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
Refresh Tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope.
Now, to answer your question on why you were still being issued a refresh token instead of just securing an access token, the main reason provided by Internet Engineering Task Force in Refresh tokens is:
There is a security reason, the refresh_token is only ever exchanged with authorization server whereas the access_token is exchanged with resource servers. This mitigates the risk of a long-lived access_token leaking in the "an access token good for an hour, with a refresh token good for a year or good-till-revoked" vs "an access token good-till-revoked without a refresh token."
For a more detailed and complete information of OAuth 2.0 Flow, please try going through the following references:
OAuth 2.0 Flow: Server-side web apps
The OAuth 2.0 Authorization Framework issued by Internet Engineering Task Force (IETF)
SO post - Why Does OAuth v2 Have Both Access and Refresh Tokens?
The refresh token serves at least two purposes. First, the refresh token is a kind of 'proof' that an OAuth2 Client has already received permission from the user to access their data, and so can request a new access token again without requiring the user to go through the whole OAuth2 flow. And second, it helps increase the whole flow of security when compared with a long lived access token. I'll touch on both of these points in a little more detail.
Refresh Tokens as a Means to Not Annoy the User
Let's talk about the first purpose with an example. Suppose you, a User, were using a third party Client web application that wanted to interact with your YouTube account data. Once you grant permission to the Client application to use your YouTube data, would you want the Client app to prompt you for your permission again when its YouTube token expired? What happens if the YouTube token expiry time was something very low, like 5 minutes. It would get a little annoying having the Client application prompt you for your permission at least every 5 minutes! The solution that OAuth2 proposes to this 'problem' is refresh tokens. By using refresh tokens, the access token can remain short-lived (which is desirable in case the access token is leaked or stolen somehow), and the refresh token can remain long(er)-lived, allowing the Client to get a new access token when one expires without requiring the user's permission (again).
But why a refresh token? If the point is to not bug the User with permission requests, then why can't the Client simply say "Hey, Authorization Server, I want another access token. Now!"? Or, "Hey Authorization Server, here is my expired token, give me a new one!". Well, the refresh token serves as a kind of "proof" that the Client at some original point in time was granted access by a User. This "proof" is in the form of the refresh token being digitally signed by the Authorization Server. By the Client presenting a refresh token, the Authorization Server can verify that the Client received, at some point in the past, permission from the User, and the Client does not have to prompt the User again.
Refresh Token as a Means to Increase Security
However, this raises the question, "Well, what happens if the refresh token is leaked or stolen, or simply kept by a malicious Client application that doesn't get rid of it at the user's request? Can't the attacker just continue to use the refresh token to gain a valid access token indefinitely (or until it expires)? This question leads to discussing the second purpose that I mentioned, of refresh tokens contributing to a more secure flow.
The issue that arises with access tokens is that, once acquired, they only ever get presented to the Resource Server (YouTube for example). So if an access token is stolen or compromised, how do you tell the Resource Server not to trust that token? Well, you can't really. The only way to do it would be to change the private signing key on the Authorization Server (the key that signed the token in the first place). I imagine this is inconvenient to do, and in some cases (like Auth0), is not supported.
On the other hand, refresh tokens need to be presented to the Authorization Server frequently, and so if one is compromised, then it is trivial to revoke or deny the refresh token as a whole, and not have to change any signing keys.
Here is the information from the OAuth 2.0 documentation.
Refresh tokens are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner).
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
(A) The client requests an access token by authenticating with the
authorization server and presenting an authorization grant.
(B) The authorization server authenticates the client and validates
the authorization grant, and if valid, issues an access token
and a refresh token.
(C) The client makes a protected resource request to the resource
server by presenting the access token.
(D) The resource server validates the access token, and if valid,
serves the request.
(E) Steps (C) and (D) repeat until the access token expires. If the
client knows the access token expired, it skips to step (G);
otherwise, it makes another protected resource request.
(F) Since the access token is invalid, the resource server returns
an invalid token error.
(G) The client requests a new access token by authenticating with
the authorization server and presenting the refresh token. The
client authentication requirements are based on the client type
and on the authorization server policies.
(H) The authorization server authenticates the client and validates
the refresh token, and if valid, issues a new access token (and,
optionally, a new refresh token).
#Teyam mention SO post Why Does OAuth v2 Have Both Access and Refresh Tokens? but I prefer the another answer there: https://stackoverflow.com/a/12885823/254109
TL;DR refresh_token does not bring increased security. It's for the purpose to improve scalability and performance. Then, access_token may be stored just in some fast, temporary storage (like memory). It allows the authorization and resource server separation, too.
Using only Access Token is much more risky than using both Access Token and Refresh Token.
For example, you use only Access Token set "100 days" expiry date but one day, Access Token is stolen by a hacker. Now, the hacker has the big chance to freely use the Access Token for 100 days as a maximum for bad purposes.
Now, you use both Access Token set "60 minutes" expiry date and Refresh Token set "100 days" expiry date but one day, Access Token is stolen by a hacker. Now, the hacker has much smaller chance to freely use the Access Token for 60 minutes as a maximum for bad purposes.
Now, you will think if Refresh Token is stolen. Actually, if Refresh Token is stolen by a hacker, the hacker still has the big chance to freely use the Refresh Token for 100 days as a maximum for bad purposes. But the probability which Refresh Token is stolen is much less than Access Token is stolen because Refresh Token is used only once every 60 minutes to refresh Access Token(to get a new Access Token) while Access Token is used every time you access resources which is much more frequent.
So, you better use both Access Token and Refresh Token.
"So I don't see how this is any more secure than just giving me an Access Token from the start and not bothering with the whole Refresh Token system."
I struggled with the same question. The short answer is the refresh token is necessary to assure the credentials have not expired.
An example may help:
I have a database that stores your medical records. You consent to sharing your medical records with your spouse. Your spouse uses their Access Token to read your records from my database. Two weeks from now your spouse checks again on your medical records and the refresh token is used to ensure they still have permission (from the authentication server) to view your records. The refresh token bypasses the need for your spouse to re-enter their credentials (username and password) to the authentication server, but it does ensure they still have legitimacy to access the resource. A never expiring Access Token would not know if you had revoked your spouse's rights to access your medical records.
access_tokens are more frequently used, and ability to revoke is not very important since they are short lived.
refresh_tokens are less frequently used, and the ability to revoke is crucial since they can be used to generate new access_tokens.
Validating a signed token is less costly, but revoking is difficult.
Validating a token stored in a database is costly, but can be easily revoked.
So, signed keys can be used as access_tokens to improve performance.
Db stored keys can be used as refresh_tokens, to make it easy to revoke them.
If there was no refresh_token, it is hard to find a mechanism which provides low cost validation and easy revocation ability. So refresh_token exists due to performance reasons.
There are at least 3 somewhat related reasons for having short-lived access tokens and long lived refresh tokens.
Bearer Tokens
From the original question:
If I have the Refresh Token, I can ALWAYS use this to get a new Access Token, since it never expires.
Although you may always be able to get a new access token using a refresh token, an attacker may generally not. This is because your use of the refresh token is coupled with some proof of your identity as a client, e.g. by providing your client_secret. Such proof is not needed for access tokens, which are bearer tokens, i.e. simply presenting them is enough.
Having the access token be short-lived mitigates this otherwise unlimited power of access tokens somewhat.
Surface of attack
Access tokens are exchanged with (potentially many) resource servers, which increases the chance of leakage. refresh tokens are only ever exchanged with the authorization server.
Again, the short-livedness of access tokens is at least some level of mitigation.
Revocation
It is possible (and common) to implement access tokens as signed JWTs. In that scenario, any server (that knows the public key of the signing party, which is typically in some well known location) can validate the correctness of the access token independently. This allows for nicely decoupled architectures, in the sense that the resource servers don't have to ask the authorization server about authorization.
The drawback of such a setup is that such tokens cannot be revoked (without anything as drastic as revoking the public key of the authorization server).
By having the access tokens be short lived, they can simply be allowed to run out rather than revoked explicitly.
refresh_token pattern keeps the OAuth server in control so the server can intervene when something bad happens like access_token and refresh_token getting leaked.
e.g.
if access_token and refresh_token get into the hands of a hacker, access_token will expire shortly, the hacker might try to refresh the token but the server now has the capacity/control to not issue the access_token again (considering the server got information of the leak).
The access token have a short life span. Once, it expires you need a new access token to access protected resource. One way to obtain a new access token authenticate resource owner again and get authorization grant then obtain access token. However, this will be annoying.
This problem can be solve with refresh token. It has long life span. So you can use it to get new access token without interacting with resource owner.
Well, you may think what is the point of having token with long life-span to obtain another key with short life-span. Well, even refresh token is compromised, attacker cannot just obtain a access token from it. Reason is attacker need the client credentials along with that refresh token.
Therefore, the access token will have a short life-span(reasons for this are available in other answers) to improve the security. To avoid resource owner being annoying whenever the access token expires, OAuth is using refresh token.
It was a good learning experience and getting some idea about the token, refresh token and caching it. However, (I am curious and I am not giving any advice here) can we use the Code which returns after user sign in when using Microsoft Identity platform. CAn we just store the CodeIdToken, and use it to get the new access token whenever there is a need? Because I am thinking we use it to get the access token then should we use to regenerate the access token each time?
...
ResponseType = OpenIdConnectResponseType.CodeIdToken,
...
and
private async Task OnAuthorizationCodeReceived(AuthorizationCodeReceivedNotification context)
{
IConfidentialClientApplication clientApp = MsalAppBuilder.BuildConfidentialClientApplication();
AuthenticationResult result = await clientApp.AcquireTokenByAuthorizationCode(new[] { "User.Read" }, context.Code)
.ExecuteAsync();
}
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:
JWT Token has an expiration of 2 hours.
The token is refreshed every hour by the client.
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:
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?
If I WERE to use a refresh token, would that token be persisted with the userId and/or JWT token?
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?
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.
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 :
Either detect that there is something of this sort happening.
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.
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:
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
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.
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
Look for the matching db record using the JWT id.
Check if the valid flag is still true, otherwise reject.
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.
Optionally, you can check the db record's createdAt or updatedAt fields, and
decide not to refresh if too much time has passed.
Update the updatedAt field in the db record.
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.
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.