16

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.

7

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, or local network api call) and retrieve all the associations to the userid (apps,roles, etc.)

However if you want to stuff more 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.

  • Cheers, DL. Do you cache the roles etc. on the API server, or just hit the DB twice every time you get a request? (i.e. once for the roles and once for the actual data being requested). If you cache it, I'd be interested to know what method you use. Also, do you mean you further encryot the userid 'inside' the already encrypted token? Thanks. – Astravagrant Feb 19 '15 at 11:01
  • 1
    I haven't gotten that far into my implementation yet :) , but yeah I was thinking of using a caching server so that way I won't hit the db as often and if a role changes the cache could be removed to allow the new role queried to be loaded saved cache. In my case I would probably use Amazon AWS elsticache which is based on the open memcached but easier to configure and use. – C0r3yh Feb 19 '15 at 12:06
  • I also think it's a better idea to get all the necessary info on the resource server and not store them in a token. – Mateusz Migała Dec 21 '16 at 9:42
3

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.
  • Don't forget that even when you check authorization in the UI you still have to check authorization on the server side when a request arrives. – Chad Clark Feb 5 '16 at 21:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.