I am having some trouble grasping the role of the refresh token flow within modern SAML/OAuth/OIDC methods.
I understand that authentication is about proving a user is who they say they are, while authorization is about proving a user has access to any particular resource. I also understand that refresh tokens can be used to to handle both.
My question is, how does the refresh/access token flow fit within authentication/authorization methods like OAuth2.0 and OIDC? Is it a subset of these auth methods, or just an optional technique sometimes employed by them? Or are they unrelated to and are like comparing pineapples to oranges?
When it comes to building authentication into a system using the refresh token flow, it is not considered OAuth or OIDC unless if it is built to specifications defined here, correct?
edit: To be more succinct - OAuth seems like a "complete" authentication method. Is the refresh token flow also considered a "complete" solution alongside OAuth, or is it just a technique that is used within OAuth?
When the user has authenticated and got the access token, it will expire after a pre-configured time (e.g. 10 minutes). But to keep the user signed in longer than the expiration time, a refresh token can be used to request a new access token (e.g. valid for additional 10 minutes), and you typically also get a new refresh token.
In other words, the refresh token is a way to keep the "user session" alive for longer than the expiration time of an access token.
A refresh token typically have different security properties, e.g. it can typically only be used one time.
I am considering to use JWT. In the jwt.io example I am seeing the following information in the payload data:
"admin": true
Admin can be considered as a Role, hence my question. Is setting the role in the token payload a habitual/good practice? Given that roles can be dynamically modified, I'm quite interrogative.
The official JWT site explicitly mentions "authorization" (in contrast to "authentication") as a usecase for JWTs:
When should you use JSON Web Tokens?
Authorization: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains.
That being said, from a security-perspective you should think twice whether you really want to include roles or permissions in the token.
(The text below can be understood as a more "in-depth" follow up to the rather short-kept accepted answer)
Once you created and signed the token you grant the permission until the token expires. But what if you granted admin permissions by accident? Until the token expires, somebody is now operating on your site with permissions that were assigned by mistake.
Some people might argue that the token is short-lived, but this is not a strong argument given the amount of harm a person can do in short time. Some other people advocate to maintain a separate blacklist database table for tokens, which solves the problem of invalidating tokens, but adds some kind of session-state tracking to the backend, because you now need to keep track of all current sessions that are out there – so you would then have to make a db-call to the blacklist every time a request arrives to make sure it is not blacklisted yet. One may argue that this defeats the purpose of "putting the roles into the JWT to avoid an extra db-call" in the first place, since you just traded the extra "roles db-call" for an extra "blacklist db-call".
So instead of adding authorization claims to the token, you could keep information about user roles and permissions in your auth-server's db over which you have full control at any time (e.g. to revoke a certain permission for a user). If a request arrives, you fetch the current roles from the auth-server (or wherever you store your permissions).
By the way, if you have a look at the list of public claims registered by the IANA, you will see that these claims evolve around authentication and are not dealing with what the user is allowed to do (authorization).
So in summary you can...
add roles to your JWT if (a) convenience is important to you and (b) you want to avoid extra database calls to fetch permissions and (c) do not care about small time windows in which a person has rights assigned he shouldn't have and (d) you do not care about the (slight) increase in the JWT's payload size resulting from adding the permissions.
add roles to your JWT and use a blacklist if (a) you want to prevent any time windows in which a person has rights assigned he shouldn't have and (b) accept that this comes at the cost of making a request to a blacklist for every incoming request and (c) you do not care about the (slight) increase in the JWT's payload size resulting from adding the permissions.
not add roles to your JWT and fetch them on demand if (a) you want to prevent any time windows in which a person has rights assigned he shouldn't have or (b) avoid the overhead of a blacklist or (c) avoid increasing the size of your JWT payload to increase slightly and (d) if you accept that this comes at the cost of sometimes/always querying the roles on incoming requests.
Nothing stops you from creating claims to store extra information in your token if they can be useful for your client.
However I would rely on JWT only for authentication (who the caller is). If you need to perform authorization (what the caller can do), look up the caller roles/permissions from your persistent storage to get the most updated value.
For short-lived tokens (for example, when propagating authentication and authorization in a microservices cluster), I find it useful to have the roles in the token.
As mentioned here, ASP.NET Core will automatically detect any roles mentioned in the JWT:
{
"iss": "http://www.jerriepelser.com",
"aud": "blog-readers",
"sub": "123456",
"exp": 1499863217,
"roles": ["Admin", "SuperUser"]
}
and 'map' them to ASP.NET Roles which are commonly used to secure certain parts of your application.
[Authorize(Roles = "Admin")]
public class SettingsController : Controller
The server which is giving out (and signing) the JWT is commonly called an authorization server and not just an authentication server, so it makes sense to include role information (or scope) in the JWT, even though they're not registered claims.
I am working on a api server which revives requests from a mobile app. I am using JWT with ASP.Net MVC Web API 2. In this Admin gives access of various departments to mobile app users. I set these DeptIds in Claims at the time of Login. On every authorised request from app, in a custom action filter attribute I read claims to match deptId in request URL with claims. This all scenario works fine.
Now my problem is, when Admin revokes access of any particular dept from app user, how should I expire the access_token of that user so that, on Login request call, I can set new Claims. Otherwise, as Admin removes access from server but the deptId still exists in user's Claims so user still have access to that department.
One way is on every request, check in database for access but that increases overhead of server also increases response time. So I don't want to go this way.
I didn't find anything on web how to expire token in JWT. Can any one help on this?
A JWT token happens to be a kind of token that allows it to be self-contained i.e. one can validate it without consulting an external entity.
That also means that there's no external entity that will tell you that the token was revoked or expired. Expiration can only happen by some property in the JWT itself; the exp claim was standardized for that purpose: it will tell the recipient the time after which the information in it must no longer consider to be valid
Authentication and Authorization are different things.
Use JWT for Authentication but not for Authorization. I mean that using JWT you can know who the user are but don't put information about what user can do into the JWT. Check permissions for the user on the server side basing on just user's identity that you got from JWT. You may also put into JWT some information that additionally limits access rights (i.e. blacklisting; for example, social network site creates an access token for a game to access my identity and friends list but not my posts) but don't put there information that directly provides access to some features (i.e. whitelisting). In that way you can easily remove access to some features on your sever-side despite that fact that the user is already logged in with JWT.
I understand you are interested in revoking or invalidating tokens instead of expiring them.
Revoking or invalidating tokens
Unfortunately it's not possible to achieve it
without keeping the track of the tokens somewhere:
Issue a token and add it to a whitelist to keep the track of it.
When validating a token, check the whitelist and refuse the request if it is not whitelisted.
To revoke or invalidate a token, remove it from the whitelist.
This security schema require some trade-offs. Deal with it.
Performance considerations
Regarding your performance concerns: Bear in mind that premature optimization is the root of all evil. You shouldn't optimize until you have a performance problem and you have proven that the performance problem comes from the way you store your tokens.
You could start storing the tokens in the database and then consider a cache in memory, for example. But always be careful when fixing a problem that you currently don't have.
Token identifier
The jti claim should be used to store the token identifier on the token. When validating the token, ensure that it's valid by checking the value of the jti claim against the token identifiers you have on server side.
For the token identifier you could use a UUID.
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.
I have a server which protects its api with an ouath2 authentication.
The scenario:
User asks for a token (password flow).
User deactivates\deletes its account.
The token is still valid (I know that its possible to invalidate token but there is another scenario where user generates tokens from 2 different clients (browser\mobile) or 2 different browsers -> receives two valid tokens -> impossible to invalidate 2 different token so one is still valid).
How should I protect my API from a valid token that it's owner isn't relevant anymore?
Should I invalidate all tokens related to the user in the account deactivation\deletion moment? Not sure if its a good idea to store in the database all user's tokens.
Should I check that the user is still active for every operation after token verification? Its a big overhead for such an end case.
*In a situation where all user's related data is being deleted as well there is no problem (the api's response will be empty), but there are cases where this data isn't being deleted.
Thanks!
You can reduce the lifetime of access tokens and use them in combination with refresh tokens. Your information will only ever be as stale as the lifetime of the access token so set it to whatever you think is acceptable, at the cost of your clients having to go back to the Authorization Server to get a new access token (this is where the deleted account check takes place). See: Why Does OAuth v2 Have Both Access and Refresh Tokens?.