21

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.

Improve this question
2
  • reading this now.... and would like an update if you can. I would be interested in what you did, as i am facing the same.. thinking and i am missing how some of the parts are intended to work. user gets authorization token, but then how are claims meant to be carried... could you explain on your findings... as it would probably help me.
    – Seabizkit
    Dec 3, 2019 at 7:25
  • @Seabizkit Sorry, probably too late to answer this, but in case anyone else is interested, I kept the JWT claims to a minimum, since I had various apps using the same authentication service. If I had a more single-purpose app/authN/authR chain, I would likely use the JWT for more claims. So, in short, it depends how you are using it. I haven't done this for a while, but I would definitely look at IdentityServer's approach and advice on this (LeastPriviliege/Dominic Baier et al.). They have put serious thought and effort into these considerations.
    – Astravagrant
    Jan 26, 2021 at 13:01

2 Answers 2

Reset to default
10

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.

Improve this answer
4
  • 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, 2015 at 11:01
  • 3
    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.
    – dynamiclynk
    Feb 19, 2015 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.
    – cah1r
    Dec 21, 2016 at 9:42
  • so for every request you get the users roles... claims..., could you point me to an article of or something which shows this as being feasible. currently im using session, but looking for a better way of doing things, but lookup on every request doesn't feel right?
    – Seabizkit
    Dec 3, 2019 at 7:20
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.
Improve this answer
1
  • 2
    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, 2016 at 21:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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