I am using JWT tokens in HTTP headers to authenticate requests to a resource server. The resource server and auth server are two separate worker roles on Azure.
I cannot makeup my mind as to whether I should store the claims in the token or attach them to the request/response some other way. The Claims list affects rendering of client-side UI elements as well as access to data on the server. For this reason I want to make sure that claims received by the server are authentic and validated before the request is processed.
Examples of claims are: CanEditProductList, CanEditShopDescription, CanReadUserDetails.
The reasons I want to use the JWT token for them are:
- Better protection against client-side editing of claims (i.e. hacking claims list).
- No need to look up the claims on every request.
The reasons I don’t want to use the JWT token:
- The auth server then has to know the app-centric claims list.
- The token becomes a single point of hack-entry.
- I’ve read a few things saying that JWT tokens aren’t intended for app-level data.
It seems to me that both have drawbacks, but I am leaning towards the inclusion of these claims into the token and just want to run this by people who have dealt with this before.
NOTE: I’ll be using HTTPS for all API requests, so it seems to me that the token will be safe ‘enough’. I’m using AngularJS, C#, Web API 2 and MVC5.
2
I store identifier claims only (userid, etc.) (encrypted) in my jwt.
Then when I get the token on the server (API) I can do a lookup server side (db,redis, or local network api call) and retrieve all the associations to the userid (apps,roles, etc.)
However if you want to stuff more unencrypted claims into the jwt just be careful with the size since it will likely be sent on each request, but make sure to encrypt sensitive claim data.
4
It sounds like authentication (who the user is) and authorization (what the user is allowed to do) are not as clearly divided as you would like.
If you don’t want the authentication server to know what the user is entitled to then limit the claims in that JWT to the userid just like wchoward suggested. You could have another server known as the authorization server look up what the user is entitled to.
The authorization step could be done by the resource server when first presented with an authentication token by the client. The resource server would then send a token to the client containing authorization claims.
Note: Both JWTs should be signed by different keys.
Pros:
- Authentication and authorization are managed separately.
- The resource server does not have to look up authorization on each request.
- The UI has access to see authorization but not edit it.
Con:
- The client needs to handle two tokens instead of one.
- Adding an authorization server adds another moving part to manage.
1