The main our product is Public API. We use IdentityServer4 for the authentication and authorization of our users. Now I'm fighting with my teammates about the number and type of information that can be in claims in token. For instance, usually, we add the user identifier and the identifier of user's organization in claims.
Also, we add user's configuration, such as
server URL where the user was provisioned
internal identifier of the user
user's device identifier
These user's configuration properties are requested from different internal services and databases during authorization and generating JWT tokens.
There is an option - keep in JWT token only the user identifier and request all configuration properties in the API method.
The main pros of keeping configuration in claims from my point of view are decreasing requests to other services and to the database.
Perhaps, there are best practices about my question from reliable sources or even in RFC what the information can be in claims?
There are no RFCs or standards which would say what information can end up in claims and which don't. I would try to stick to those guidelines:
Try to keep information in tokens as minimal as required. Don't put something in claims only because maybe one service will need it from time to time. Put only those claims which most of the service use all the time, or information which needs to be asserted by the Authorization Server. The other data usually belong to the microservices themselves or can be easily obtained through API calls. This is especially important if you're using JWTs publicly available on the Internet, as anyone can read those information.
Try not to put Personally Identifiable Information in a JWT, especially if the token is available publicly. When someone steals such a token they will be able to read your users' PII. If you need this kind of information in a token, then think of using the Phantom Token pattern. This way the information is safe from eavesdroppers.
By limiting the amount of claims in a token you can also limit the permissions of a token. It's better to have tokens with lower permissions and use token exchange whenever more information or privilege is needed.
Remember that the claims in the token are a contract between the Authorization Server and the consumer (usually the API). Once you add something to a token, you usually won't be able to remove it, as this will constitute a breaking change.
Have a look at these articles we wrote at Curity to get some more knowledge about dealing with claims and JWTs:
Claims Best Practices
JWT Security Best Practices
Related
I have a problematic and a potential solution and i'm wondering if it's a good solution or if a better way of doing things exists.
I have an API A called by a frontend with a JWT token.
If the service doesn't have the solution I would like this service to fetch the solution from another API B.
Is it a good idea to forward the JTW token I received from the Front User and authenticate to the API B as this user to request my data (knowing that the JWT may carry useful information) ?
Should I maybe drop the JWT and authenticate in a different way to this API ?
Is there an industry standard for theses kinds of things or good pratice?
JWT access tokens are designed to be forwarded between APIs. Doing so maintains an auditable user identity. Each API then verifies the JWT signature, issuer, audience, scopes and claims. This is sometimes called a zero trust API architecture - but there are caveats.
SCOPES
Design these in terms of areas of business data. Eg client has scopes orders shipping and calls an Orders API. The Orders API can then forward the JWT to the Shipping API. Each API must check for the scopes it needs.
SAME TRUST LEVEL
As always, you need to think about threats. My above recommendations are for APIs split into microservices, often for technical reasons, eg smaller code sizes and multiple development teams.
DIFFERENT TRUST LEVELS
Consider forwarding a JWT to a Shipping API in a subdivision of a large company. You may not trust to give them the orders scope. In that case, use token exchange to get a new token with only the shipping scope, then forward that to the upstream API.
SUMMARY
Always aim to forward a JWT that maintains an auditable user identity. Use scopes as one ingredient to ensure least privilege. Also evaluate threats, to prevent potential exploits.
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've done a fair amount of research on the many different ways to authenticate and authorize users who use my frontend application to access my REST API. I've built a system that uses OAuth2 and JWT and need a sanity check since I'm working on this alone.
For a bit of background, my frontend is built using Vue.js and my API is built using Django with Django Rest Framework. My team is already planning on concurrently developing the mobile and desktop versions of this app which both would require authentication and authorization as well.
To keep things brief, I'll omit the alternative solutions I have and just talk about the most controversial one.
Right now, OAuth2 (my authorization server) grants users a JWT token using ROPC when they provide their email and password to my frontend client. I should note that my API (my resource server) and authorization server live on the same machine.
My application allows users to essentially signup using different plans (for example a free plan and a paid plan). When a user signs up for a free plan, I need the frontend application to not only disable certain features and elements in the UI, but also I need the authorization server and or resource server to limit what that user is allowed to query based on their plan.
The idea is when a user signs up or logs in, my authorization server will get the associated user record from the database and create a valid JWT with a claim attached that states the user's plan and maybe some other non-personal information. Then once signed it sends it off to the user where the frontend can enable/disable parts of the UI... etc. Hence, if a user logs in on mobile, we can customize the UI based on the same claim sent by the JWT.
My issue is that I don't know if this is a good way to go about it. It seems that everyone I've asked in my circle is split on using JWT or not. Those apposed mostly raise security issues, but, when from what I understand, many of the JWT security pitfalls are well documented and can be avoided just using some commonsense as with any other session/token-based authentication. I'm starting to get analysis paralysis. Please help.
CLASSIFICATION
I would say this is really an API Authorization question, as opposed to an OAuth question:
The role of the Authorization Server and tokens is really just to prove the user's identity
Product specific logic comes after the user logs in and is generally best handled in your app
MY PREFERENCES
Here is how I would handle it:
Save the plan type to your product data when the user signs up
After login, look up the user from the access token
Then look up the user's plan type from your product data
Produce a Claims / Principal object in your API containing both
Enforce business rules based on the plan type claim
I would aim for a Claims object something like this:
class ApiClaims {
// The user id in the access token
userId: string;
// The email
email: string;
// The plan type
planType: string;
// Other claims from the token
// Other claims from product data, eg user roles
}
RESOURCES
If interested in this approach, these blog posts of mine may be of interest:
User Data Management
API Authorization
JWT?
You need some kind of API credential that is sent in HTTPS messages and is web and mobile friendly, so I would use JWTs. You could follow the same pattern with any API credential though.
It depends on what you are trying to protect of course, but JWT bearer tokens are an industry standard. Since you control both the client and the authorization server, you can implement it however you like.
I would look into changing Resource Owner Password Credentials flow to authorization code flow. It will enable you to use social authentication providers like Google or Facebook to sign in users (while still maintaining plan info in your own service). Chances are that people trust those companies more to keep their credentials safe than your company, and it allows you to benefit from any authentication features (MFA) those companies implement.
Also, if you want the clients to read the contents of the token, you should use OpenID Connect id_tokens, as those are guarenteed to be in JWT format.
I'm trying to follow OpenID Connect best practices. For the simple scenario of calling API from application the OpenID Connect suggest to pass the Access Token (which is not included user identity), and if the API in some points need the user identity it should call /userinfo endpoint of OpenID Connect provider.
So the question is: Is it the best way to get the user identity in API?
Assume I have an end point named CreateOrderForCurrentUser() so each time any user call this api I need to call the /userinfo endpoint, it seems too much cost for calling an api.
Why I don't pass the Identity token to the API?
Or Why I don't put some identity claims in Access token?
Should I use HOK Token instead of Access token?
Any idea please.
It seems here is kind of same as my question: Clarification on id_token vs access_token
And he respond in comments: https://community.auth0.com/t/clarification-on-token-usage/8447#post_2
Which as my understanding means: put some identity claims in Access token (Custom Claims) and rely on that in the API.
But still it doesn't make sense. The OIDC insist to not use Access token as Identity and now we are going to add identity claims inside Access Token. Could any one clarify that?
ID_Token is used for your client app tells the app who you are , the audience of the ID Token is the id of your client app , with access token , API/resource knows whether authorized to access the API and perform specific actions specified by the scope that has been granted.
By default , it will include user identifier in access token(sub claim) , so you should know which user when calling CreateOrderForCurrentUser function . You could customize the access token to include more user related claims if needed . But i would suggest to simplify the access token , and you could use access token to acquire user information by invoking user's API endpoint .
I asked the same question in Auth0 Community and there is a discussion about it that might be helpful for others who have the same issue.
I copy the same answers here:
markd:
You are correct that you should not use an access token as proof of identity, but before you get to your API you should have already authenticated the user and received an id_token for them. If you have already authenticated the user via OIDC, as far as I know there’s nothing wrong with adding custom claims to the access token to pass data to your API. Your API could also use the client credentials grant type to pull data from Auth0.
Me:
I’m looking for the best practices. I want to be sure adding identity claims to the access token and rely on that in API does not broke any thing and is based on best practices or maybe the best practice is always call the /userinfo endpoint in API and don’t rely on Access token identity claims.
The API doesn’t know about the authentication process and don’t care about that. Any one any how pass the signed Access token to the API, it would be accepted. Now in API point of view is that proper way to rely on identity claims in Access Token? I have doubts. But I would be happy if we could ignore calling the /userinfo end point each time.
jmangelo:
I can share some (hopefully) informed views on this subject, but please do take them with a grain a salt and question stuff you disagree with or you don’t consider clear enough. When it comes with software the devil is on the details and in the security landscape it’s even more true so you need to consider best practices as what will likely be recommended for the majority of the scenarios and also what will likely be less risky; it does not mean that nothing else is possible.
For example, although the recommendation is indeed to use access tokens in requests to API’s this does not mean that there isn’t a specific scenario where technically it would also be okay to send an ID token instead.
Focusing on your particular questions and starting with the last one (3); we should not compare HOK and access tokens because they are not at the same level. In other words, you could question if in your scenario you should use bearer tokens or HOK tokens as this way and using the terminology of your linked page you would be choosing between two token profiles where each give you different characteristics.
At this time, the access tokens issued by the Auth0 service as part of API authorization are bearer access tokens so this question has only one answer if using the Auth0 service.
Jumping to the first question; it’s not that you cannot pass the ID token to the API, it’s just that the scenarios where that would be adequate are much more constrained. For example, an ID token is issued with the client identifier as the audience; it’s common to have multiple client applications so you have just coupled your API to how many client applications you have, because assuming you will validate the audience of the ID token, your API would now need to know the identifiers of every client.
For question (2) which I assume is also interested in why call /userinfo if you can include claims in the access token. I believe this can depend a lot on requirements and/or personal preferences. At this time the only format supported when issuing an access token to a custom API is the JWT format.
The above means that you have a self-contained token that once issued the API can mostly validate independently which is great in terms of scalability because the API does not need to make (frequent) external calls for validation purposes.
However, being self-contained this immediately means that any data you include directly in the token will be considered the truth for the lifetime of the token itself. If instead the API is calling /userinfo or even the Management API directly then you ensure fresh data at the cost of network overhead.
In conclusion, in my personal view the choice between network calls and embedded claims is more tied to the characteristics of the data you are interested in that just from a best practices point of view.
As a final note, even without any addition of custom claims an access token issued by the service in association to a custom API already conveys user identity. In particular, given the access token is a JWT, the sub claim will contain an identifier that uniquely identifies the end-user that authorized the current application to call the API on their behalf.
Why use the proposed OpenID OAuth Extension over another OAuth-based protocol?
Discovery doesn't seem to be a feature. Although the consumer only needs a claimed identifier to start the authentication process, any authorization will still require that the consumer knows the access token URL, signature methods, and have a shared key/secret with the provider.
One benefit is that there's a specified way to ask for specific authorizations, the openid.oauth.scope argument to the authentication request. And one specific benefit for this is that authentication only - for the benefit of the consumer only, with no verifiable token - is defined for free and can be performed without worrying about keeping track of outstanding tokens or the resources they might require.
Are there examples of alternative ways in use to specify the scopes to be requested, perhaps with something in OpenID discovery? Or could this be handled effectively with some kind of REST navigation before the OAuth process, where one of several request token URLs specific to the desired scopes is discovered by interpreting hypertext starting from a well-known URL?
I am researching a delegated authentication and authorization system with several authorization scopes, where the scopes are relevant for different interactions. In other words, the consumer needs to tell the provider which scopes should be presented to the user for authorization.
The OpenID+OAuth extension really has only one significant advantage over standard OAuth:
If you need to authenticate the user and access the user's private data, and the OpenID Provider happens to also be the OAuth Service Provider (the user authenticates with the same service that holds his private data), then the extension will help the user have just one redirect to the OP+SP instead of two separate ones. For the user, this is a huge usability win -- if he happens to be authenticating with his SP.
The risks of supporting the extension is adequately supporting users whose OP and SP are not the same entity (you don't want to say you'll support the extension and then inadvertently lock out users whose OP is not also their SP).
Keep in mind what you really need to know. If you only want to access the user's private data, but don't really care who the user is that you're interacting with, use just OAuth. No reason for the user to give up his identity via OpenID if you're only downloading his photos to offer a photo printing service, for example, or if you already have a non-OpenID account for this user.