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.
Related
This is a typical token-based auth sequence. The initial sign-in sends username/password, receives a token that is used for all subsequent requests. The tokens are only valid for a set amount of time.
If there was a malicious listener on the network that sniffs a token, they can impersonate the client, but exposure is time-limited. But if there was a listener on the network who can sniff tokens, wouldn't they be able to sniff the initial sign-in request and continue to request their own tokens forever?
At that point doesn't the whole setup devolve to the equivalent of sending an irrevocable API key with every request?
I would say the key benefits of JWTs are around the security ecosystem and design patterns it gives you. Much of this behaviour is implemented by an Authorization Server and reduces the work you need to do:
JWTs are time constrained as you say, meaning that for all scenarios other than those where there is an edge case of a permanent listener, they are more secure.
Internet clients should use confidential access tokens that do not reveal any confidential data - it is common to use reference tokens (eg UUIDs) - see the Phantom Token article for how this works.
JWTs encourage patterns where APIs receive digitally verifiable scopes and claims that can be trusted and used for authorization - whereas an API key could easily grant access to too much data.
A mechanism for both user friendly sessions and revocation in the face of data breaches is provided by using refresh tokens and access tokens together. Eg an access token only lives 15 minutes while a refresh token lasts 8 hours. Apps have to check in with the Authorization Server every 15 minutes, but this only rarely impacts the user.
Token issuing is audited in a database (along with user consent if relevant) and available after the event - eg for your InfoSec staff.
JWTs can be sender constrained in some scenarios, such as for financial grade connections between business partners, so that an attacker cannot use a token that they intercept.
An API key could actually be designed to work like a reference token, since they feel the same to a client. You would then need to do a lot of custom work in your back end though. Whereas a free Authorization Server will do this work for you.
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
For most client applications and UI approaches JWTs seem to be a good way to carry tokens for an OAuth based approach. This allows decoupling of a User/Auth service and the services that are actually being accessed.
Given this architecture
My question is: in the case of public APIs (ie Github or Slack) where a bearer key is generated with specific roles. How is that key authorized in a microservice architecture? Do those types of keys just require that the Auth service gets queried with every request?
Could an API gateway mitigate this? I would like to understand if a solution exists where there is minimal communication between services. Thank you!
Normally, this is solved using scopes. The scopes are permissions given to a user to do certain operations,for example there will be a scope for read a repository, another for update it, another one for delete etc..
These scopes are tied to the token and normally are requested by the user himself or added automatically depending on the user type. And the same as the authentication process, they could be included in the token itself coded as a claim in a jwt or they could be requested or checked by calling an oauth server when one operation is requested.
The advantages of include them in jwt is that there is not need to call an external server every time an operation is requested so there is a lower latency and less bandwith is required, also you remove a point of failure. Obviously if this solution is used the token must be properly signed or even encrypted to avoid possible manipulations.
However it has also drawbacks, and the most dangerous one is that the token cannot be revoked because this information cannot be included in the token and the service that check if the token is valid only can access the data contained in the token itself. Because of this, this kind of tokens are normally issued with a little expiry time so in case of the token is stolen, the validity of it will be very limited
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))