Roles using JWT

Question

I am new to JWT. I studied a bit about JWT and understood that it is framed as "header.claims.signature".

Consider a simple scenario as follows:

A customer gets authenticated
Customer may have (one or more) roles of admin, member, registered, guest
The server does not maintain any session (and depends solely on JWT for authentication/authorization)

Once authenticated, the server finds the type of customer and I am assuming that the customerId and the roles will be part of "claims" in JWT. Let me know if my assumption is incorrect (or against standard).

The "claims" part of JWT is not encrypted (just encoded). That exposes an easy security hole, where the (service) consumer can simply modify "claims" part of JWT and resend the same with more roles (for which the customer/consumer is not authorized to).

If my understanding/assumption is incorrect, how do we achieve to what I am targeting?

score 31 · Accepted Answer · edited Oct 07 '21 at 05:46

31

When using JWS (header.claims.signature), the "claims" part of the JWT is integrity protected by the signature. So if the "claims" or any other part of the JWT is modified by someone without the proper key, the signature verification on the JWT will fail and the token should be rejected.

edited Oct 07 '21 at 05:46

Community

1
1

answered Aug 23 '15 at 14:46

Brian Campbell

2,293
12
13

If I modify "admin" to "false" at http://jwt.io/, it looks like, the signature does not really care about it. Am I missing something here? – user203687 Aug 24 '15 at 14:10
10

The tool at jwt.io is updating the signature as you modify the JSON claims. If you were to modify the JWT elsewhere and paste it in, you'd get invalid signature reported by the tool. For example this JWT has the signature calculted over claims w/ "admin":false but then the claims/payload modified to "admin":true and thus the signature isn't valid: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.uI_rNanTsZ_wFa1VnICzq2txKeYPArda5QLdVeQYFGI – Brian Campbell Aug 24 '15 at 16:39
@BrianCampbell: Excellet! Exactly what I'm looking for! – sk8terboi87 ツ Apr 30 '17 at 07:16

Hamid Mohayeji · Answer 2 · 2018-02-19T13:22:58.790

10

The claims part of JWT can be verified, but another issue when adding something like roles to claims is the case when you change user roles, but the old token still contains the previous roles assigned to the user. So be careful about it. You can simply keep user identifier in the token and retrieve any other information associated with the user based on your persistence mechanism (databases or anything else).

edited Feb 19 '18 at 13:22

answered Sep 04 '17 at 11:37

Hamid Mohayeji

3,977
3
43
55

1

Access tokens are short-lived for this and many other reasons. Azure AD tokens are valid for 1 hr only for e.g. – Sat Thiru Apr 07 '18 at 23:43
I was searching this answer. Thank you a lot. – Halil İbrahim Oymacı Jan 01 '19 at 11:33

score 2 · Answer 3 · answered Nov 12 '15 at 17:31

Another option is to look up the user in a database during authentication, based on a user identifier included in the token, to verify roles or other aspects of their identity not included in the JWT.

However, any information included in the JWT is verified via signature as previously stated, so you can also rely on what is in the JWT if required.

Roles using JWT

3 Answers3