2

I am an application developer and am building a token-based auth mechanism for my application. Essentially, the user will log in with username+password, if the credentials are valid, my code will generate a JWT (probably going with a 30-minute expiry, at least to start with).

If they attempt to request authenticated resources, they will need the JWT stored as a bearer token in their HTTP auth header. When this happens, I'll verify/validate the JWT, and if its good, give them access.

Right now I'm struggling with a particular aspect of the design here and I was wondering what the security best practices dictate in such a situation, and that is: what information can/should I put as "claims" on my JWTs?

I guess to start with, I'm not entirely sure what the underlying intent of a JWT claim is, which might help point me in the right direction.

But basically, with respect to my authorization scheme, I'm wondering if it is a good practice (or not) to not only place something in the JWT that identifies the requester as a principal in the system (identification), but also to place claims on that token regarding access control; meaning, do I put a list of all my user's roles, ACLs, etc. on a JWT claim?

Beyond authorization-related data, what other information do you typically see (correctly) added to a JWT in the form of claims? Thanks in advance for any and all help!

1 Answer 1

Reset to default
5

JWT's can be used for anything you want the server side to communicate back to itself or other services in the ecosystem in a trusted manner through an untrustworthy client. The user principal, display name, and resource authorizations would all be sensible. That spares the server from going to a DB to look these things up prior to doing work.

Use your imagination though. What are some things you server side normally has to look up in a database or in another service because the client isn't trustworthy? Which of those things is static at the user or session level? Those things make for reasonable claims, IMO.

4
  • Fantastic answer, and it makes the solution 100% obvious in hindsight :-) Thank you.
    – hotmeatballsoup
    Commented Nov 15, 2020 at 19:05
  • Would it be a good idea to store all of the user's allowed resources_ids in the JWT? It could make it too heavy
    – Juan Perez
    Commented Jun 2, 2023 at 15:08
  • 1
    @JuanPerez It likely depends on how granular that resource list is and how expensive it is to build comprehensively ahead of time versus individually (per-resource) at request time. Ideally, you'd want to do a little math for a few options and benchmark and/or stress test to confirm. In some cases, you just want to invert the problem. Use the JWT only to authenticate the session. Use ACL's in the service (e.g., on the individual records) to authorize access. (I'd actually assume the latter is the more routine approach.)
    – svidgen
    Commented Jun 2, 2023 at 15:44
  • 1
    To follow that up, I would personally tend to reserve in-JWT authorizations to very very low granularity claims, like isMemberOf: [...groups] or isSystemAdmin or fullReadAccess: [...services | ...tables] and fullWriteAccess: [...services | ...tables]. Broad authorizations like that.
    – svidgen
    Commented Jun 2, 2023 at 15:51

Your Answer

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

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