I've read several articles (such as this and this, and this SO answer) that suggest storing refresh tokens server-side in a database, or in-memory (or an in-memory store, such as Redis). From what I understand this is so they can be revoked.
Is there a good reason for storing all tokens as these articles suggest, rather than just storing blacklisted tokens on logout? If I understand the reasons for storing tokens, surely I could achieve the same effect by storing a token id in Redis (with a TTL as long as the expiry, so that the table doesn't grow unweildy).
Are there downsides to this approach, and if so, what are they (or conversely, what are the upsides of storing all tokens, vs just a list of revoked tokens?)
To elaborate, and why I think it should be fine to have a revocation list, here's the process I am imagining:
Issue tokens out
Once revoked (say, on logout), add an entry to a blacklist for a unique id (say, public_user_id if there are many tokens for different devices) with the revocation time, and add a TTL until the token's expiry
When a token is provided for auth, when there is an existing blacklist entry:
if a valid token is used, it'll be before it's expiry and have a creation time after the blacklist entry creation time for the unique id
if an invalid token is used, it'll either be expired or within the blacklist with the unique identifier before the entry creation
Am I missing something critical in that flow that would require a list of all tokens instead?
The advantage of having a list of all issued tokens is that you can have a full view of who has been already authenticated and has currently access to the system. You can then choose to revoke some tokens from this list based on any criteria (e.g. the age of the token, the roles associated with the user of the token, the IP address ranges).
If you only have a list of revoked tokens, it would be impossible to choose at runtime, an arbitrary criteria, to revoke a subset of the valid tokens. Stated otherwise, if you don't have a list of all issued tokens, the revocation criteria cannot be enforced globally at once, but only when a token is presented to a resource server.
The only deciding factor I can think of, that will require a list of all refresh tokens is the following:
Do you / will you, at any point, need to have a functionality where you can dynamically revoke valid refresh tokens, based on some arbitrary, regulatory, legal, integrity, security etc. criteria?
If so, the least you will need is a list of all issued tokens, plus any metadata required to implement the criteria logic.
Example: "Due to regulation, I need to ban all EU users" equates to delete from refresh_tokens were user_ip in <... eu logic ...>
I would aim for a direction of technical simplicity here, since the Authorization Server (AS) should do the hard work for you. Here are some end to end notes which explain some tricky aspects and suggest a simple direction.
1. TOKEN ISSUING
The user authenticates (and optionally consents) resulting in a token 'grant'. The AS should then store refresh tokens for you, in a database table that might be named 'delegations'. Typically the stored 'token' will be a hash rather than the real value, and will be linked to the application (client_id) and user (subject). Tokens issued might have these lifetimes:
Refresh token: 4 hours
Access token: 30 minutes
2. TOKEN REFRESH
OAuth clients such as mobile apps will silently renew access tokens during the lifetime of the grant or 'user session'. This involves sending a refresh token to the AS and getting back a new access token. For this to work the AS needs to store a hash of the refresh token in order to be able to validate the input.
3. DEFAULT REMOVAL BEHAVIOUR
When a user logs out, tokens are cleared from the client app, so they are gone. Newer OAuth 2.1 recommendations are to use rotating refresh tokens, where each access token refresh also renews the refresh token and invalidates the previous one. In our example this now means that the lifetime of a stolen refresh token is likely to be reduced - perhaps to only 30 minutes.
4. MANUAL REVOCATION BY ADMINISTRATOR
If for some reason you want to explicitly deny access to a particular user and application, an administrator could use the AS database and issue a command like this, though the Admin UI may provide more visual options.
delete from delegations where client_id=[value] and subject=[value]
Whether manual revocation is likely to be manageable at a people level is questionable but it is a good capability to have, eg in security reviews.
5. REVOCATION OF REFRESH TOKENS ON LOGOUT
Of course the client can revoke its own refresh tokens on logout if required, before clearing tokens. This should also ensure that any access tokens for the same grant are rejected by the Authorization Server.
6. ACCESS TOKEN VALIDITY
Access tokens are most commonly JWTs. Revocation or logout may occur when the JWT still has 25 minutes to live. If an attacker has somehow intercepted an access token (which shouldn't usually be possible) they can continue to use it against your APIs - during this period the AS will never see the access token.
7. API GATEWAY SETUPS
In a more sophisticated setup, opaque access tokens are issued to internet clients, then sent to an API gateway, which introspects them, as in the Phantom Token Pattern. The gateway also maintains a cache of the access token result.
At the time of revocation the AS can raise a Custom Event to inform the API Gateway, which can then clear any cached access tokens for the user. This should ensure that the very next request with an access token for the revoked (or logged out) user is rejected.
SUMMARY
Unless you are dealing with a very high security domain I would aim for simplicity and follow these two principles:
Leave token storage and revocation to the Authorization Server
Keep tokens short lived so that revocation becomes less of an issue
Related
For my project, I'm implementing OAuth2 authentication framework that uses Bearer tokens.
From a quick search, it looks like JWT tokens are the mainstream choice for Bearer tokens today.
If I would use a "dumb" token that doesn't encode any information, I would be storing this token in a database, alongside all the related parameters (token's user, issue date, expiration date, etc.).
From JWT's documentation I understood that I can avoid this overhead by implementing this flow:
User authenticates with one of the supported methods
Authentication service generates JWT token and encodes the following parameters into it: user id, authentication method used, issue date, expiration date
Authentication service encrypts and then signs the token
The token is sent to the user for subsequent usage
The encryption step is desirable because I wouldn't like to advertise user IDs.
My understanding is that if I use the above method, I can avoid storing the mapping between access tokens and users, and rely entirely on the user ID information provided with the token.
What disturbs me with this approach, is that it looks like I won't have the option to "revoke" access tokens.
In other words - even if access token will become compromised, I won't be able to disable it (unless I know the exact compromised token, which is not the case).
Is this a real concern, or I'm just missing somethig? If this concern is real, how can I work around it?
Access tokens self-contained and are valid as long as the expiration time is valid. There is no specification around invalidating them in the actual spec. Depending on the level of security you need you can adjust the validation time of the tokens, from fewer minutes to hours. Typically the validation time is set for an hour.
If you require higher level of security, you can use Reference tokens. Reference tokens doesn't carry any information, they are plain strings. But, the server (or whoever is consuming these tokens) has to contact the Token Provider to exchange the reference tokens for actual response content. But, these tokens can be revoked if they are compromised.
Please refer to this link for more information and some suggestions on how to overcome some of the downsides of Reference tokens (like back channel communication/ extra round trip to Token Provider). Please let me know if you have any questions.
-Soma.
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 creating an API along with a SPA for a personal project and I'm hesitating between the following solutions to authenticate users (note: over HTTPS):
HTTP Basic Authentication (send username/password wich each request)
Token based authentication (store SHA1-ed user tokens in the database)
JSON Web Token (JWT) authentication
I don't even consider OAuth cause it seems like a real pain plus I don't need to authenticate with other apps, I'm only concerned about authenticating users.
From what I've read, JWT seems to be a growing standard. It basically holds the caller's data so everytime he makes an API request you encrypt(base64(header) + "." + base64(payload)) with your secret and you compare it with the signature provided in the last part of the token itself. It avoids having to perform DB transactions.
The problem is that if I use JWT 1) I have no possibility to manually revoke specific tokens, and most of all 2) if I change a user's permissions, the previously granted JWT will still have the old data with his old permissions which could grant/restrict him continuous access to some data as long as he doesn't get a new token with his new permissions, which is really problematic and I'm surprised I haven't seen anyone mentionning this problem yet. Moreover, 3) JWT claims to allow the server to validate access without having access to DB but I can't imagine any API request that doesn't involve the database somehow, if only to return data the user asked for. So this argument doesn't make any sense to me.
To me, my best option right now is option 2. Website will have restricted and small traffic so storing tokens in the Database seems like a small and worthwhile trade-off and allow me to do anything I want with these tokens, including managing their lifecycle and permissions. It also avoids exposing the users' credentials like in option 1, in case they use the same ones for other online services.
I just want to know if my concerns about JWT are right or if I misunderstood its functioning? Also, even if I've already read a lot about these different options, feel free to link anything that could enlight me and help me make a better choice. Thanks.
You are right and invalidating tokens before expiration time is a common JWT problem. There are several reason to consider: account deleted/blocked/suspended, password changed, permissions changed, user logged out by admin.
With JWT, you can also set a token blacklist to store tokens that were between logout & expiry time, mark expired and check it in every request. You can include only the ID (jti claim of JWT) or use the last login date and the iat claim (issued at)
Other technique to invalidate tokens when user changes their password/permissions is signing the token with a hash of those fields. If the field value changes, any previous tokens automatically fail to verify.
See https://stackoverflow.com/a/37520125/6371459
Finally, be aware that the token is signed with server private key (not encrypted)
sign(base64(header) + "." + base64(payload))
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?.
i have to confess i've had this question for a very long time, never really understand.
say auth token is like a key to a safe, when it expires it's not usable anymore. now we're given a magic refresh token, which can be used to get another usable key, and another... until the magic key expires. so why not just set the expiration of the auth token as the same as refresh token? why bother at all?
what's the valid reason for it, maybe a historical one? really want to know. thanks
I was reading an article the other day by Taiseer Joudeh and I find it very useful he said:
In my own opinion there are three main benefits to use refresh tokens which they are:
Updating access token content: as you know the access tokens are self contained tokens, they contain all the claims (Information) about the authenticated user once they are generated, now if we issue a long lived token (1 month for example) for a user named “Alex” and enrolled him in role “Users” then this information get contained on the token which the Authorization server generated. If you decided later on (2 days after he obtained the token) to add him to the “Admin” role then there is no way to update this information contained in the token generated, you need to ask him to re-authenticate him self again so the Authorization server add this information to this newly generated access token, and this not feasible on most of the cases. You might not be able to reach users who obtained long lived access tokens. So to overcome this issue we need to issue short lived access tokens (30 minutes for example) and use the refresh token to obtain new access token, once you obtain the new access token, the Authorization Server will be able to add new claim for user “Alex” which assigns him to “Admin” role once the new access token being generated
Revoking access from authenticated users: Once the user obtains long lived access token he’ll be able to access the server resources as long as his access token is not expired, there is no standard way to revoke access tokens unless the Authorization Server implements custom logic which forces you to store generated access token in database and do database checks with each request. But with refresh tokens, a system admin can revoke access by simply deleting the refresh token identifier from the database so once the system requests new access token using the deleted refresh token, the Authorization Server will reject this request because the refresh token is no longer available (we’ll come into this with more details).
No need to store or ask for username and password: Using refresh tokens allows you to ask the user for his username and password only one time once he authenticates for the first time, then Authorization Server can issue very long lived refresh token (1 year for example) and the user will stay logged in all this period unless system admin tries to revoke the refresh token. You can think of this as a way to do offline access to server resources, this can be useful if you are building an API which will be consumed by front end application where it is not feasible to keep asking for username/password frequently.
I would like to add to this another perspective.
Stateless authentication without hitting the DB on each request
Let's suppose you want to create a stateless (no session) security mechanism that can do authentication of millions of users, without having to make a database call to do the authentication. With all the traffic your app is getting, saving a DB call on each request is worth a lot! And it needs to be stateless so it can be easily clustered and scaled up to hundreds or even thousands of servers.
With old-fashioned sessions, the user logs in, at which point we read their user info from the database. To avoid having to read it again and again we store it in a session (usually in memory or some clustered cache). We send the session ID to the client in a cookie, which is attached to all subsequent requests. On subsequent requests, we use the session ID to lookup the session, that in turn contains the user info.
Put the user info directly in the access token
But we don't want sessions. So instead of storing the user info in the session, let's just put it in an access token. We sign the token so no one can tamper with it and presto. We can authenticate requests without a session and without having to look up the user info from the DB for each request.
No session ... no way to ban users?
But not having a session has a big downside. What if this user is banned for example? In the old scenario we just remove his session. He then has to log in again, which he won't be able to do. Ban completed. But in the new scenario there is no session. So how can we ban him? We would have to ask him (very politely) to remove his access token. Check each incoming request against a ban list? Yes, would work, but now we again have to make that DB call we don't want.
Compromise with short-lived tokens
If we think it's acceptable that a user might still be able to use his account for, say, 10 minutes after being banned, we can create a situation that is a compromise between checking the DB every request and only on login. And that's where refresh tokens come in. They allow us to use a stateless mechanism with short-lived access tokens. We can't revoke these tokens as no database check is done for them. We only check their expiry date against the current time. But once they expire, the user will need to provide the refresh token to get a new access token. At this point we do check the DB and see that the user has been banned. So we deny the request for an access token and the ban takes effect.
The referenced answer (via #Anders) is helpful, It states:
In case of compromise, the time window it's valid for is limited, but
the tokens are used over SSL, so unlikely to be compromised.
I think the important part is that access tokens will often get logged (especially when used as a query parameter, which is helpful for JSONP), so it's best for them to be short-lived.
There are a few additional reasons, with large-scale implementations of OAuth 2.0 by service providers:
API servers can securely validate access tokens without DB lookups or RPC calls if it's okay to not worry about revocation. This can have strong performance benefits and lessen complexity for the API servers. Best if you're okay with a token revocation taking 30m-60m (or whatever the length of the access token is). Of course, the API servers could also keep an in-memory list of tokens revoked in the last hour too.
Since tokens can have multiple scopes with access to multiple different API services, having short-lived access tokens prevents a developer of API service for getting a lifelong access to a user's data on API service B. Compartmentalization is good for security.
Shortes possible answer:
Refresh tokens allow for scoped / different decay times of tokens. Actual resource tokens are short lived, while the refresh token can remain valid for years (mobile apps). This comes with better security (resource tokens don't have to be protected) and performance (only the refresh token API has to check validity against DB).
The following is an addition to the benefits of refresh tokens that are already mentioned.
Safety First!
Access tokens are short-lived. If someone steals an access token, he will have access to resources only until access token expires.
"...But what if a refresh token is stolen?"
If an attacker steals the refresh token, he can obtain an access token. For this reason, it it recommended that a new refresh token is issued each time a new access token is obtained. If the same refresh token is used twice, it probably means that the refresh token has been stolen.
When the refresh token changes after each use, if the authorization
server ever detects a refresh token was used twice, it means it has
likely been copied and is being used by an attacker, and the
authorization server can revoke all access tokens and refresh tokens
associated with it immediately.
https://www.oauth.com/oauth2-servers/making-authenticated-requests/refreshing-an-access-token/
Of course, this is just another layer of security. The attacker can still have time to obtain access tokens, until the refresh token is used a second time (either by the attacker or the real user).
Always keep in mind that the refresh token must be stored as securely as possible.