30

How do you guys deal with the same user on multiple devices? Won't data such as {admin: true} become stale except for the device that changed it?

Should this even be in a JWT? If not, and we resort to only putting the user ID, won't that be just like a cookie-based session since we store the state on the server?

user1164937
  • 1,979
  • 2
  • 21
  • 29
  • Listing some useful properties I thought were useful so far: `userID`, `lastActive`. `scopes` would be useful if you have a blacklisting feature that'll revoke all of the user's keys – user1164937 Aug 12 '16 at 00:51

1 Answers1

39

The JWT RFC establishes three classes of claims:

  • Registered claims like sub, iss, exp or nbf

  • Public claims with public names or names registered by IANA which contain values that should be unique like email, address or phone_number. See full list

  • Private claims to use in your own context and values can collision

None of these claims are mandatory

A JWT is self-contained and should avoid use the server session providing the necessary data to perform the authentication (no need of server storage and database access). Therefore, role info can be included in JWT.

When using several devices there are several reasons to revoke tokens before expiration, for example when user changes password, permissions or account deleted by admin. In this case you would need a blacklist or an alternative mechanism to reject the tokens

A blacklist can include the token unique ID jti or simply set an entry (sub - iss) after updating critical data on user (password, persmissions, etc) and currentTime - maxExpiryTime < last iss. The entry can be discarded when currentTime - maxExpiryTime > last_modified (no more non-expired tokens sent).

Registered Claims

The following Claim Names are registered in the IANA "JSON Web Token Claims" registry established by Section 10.1.

  • iss (issuer): identifies the principal that issued the JWT.
  • sub (subject): identifies the principal that is the subject of the JWT. Must be unique
  • aud (audience): identifies the recipients that the JWT is intended for (array of strings/uri)
  • exp (expiration time): identifies the expiration time (UTC Unix) after which you must no longer accept this token. It should be after the issued-at time.
  • nbf(not before): identifies the UTC Unix time before which the JWT must not be accepted
  • iat (issued at): identifies the UTC Unix time at which the JWT was issued
  • jti (JWT ID): provides a unique identifier for the JWT.

Example

{
    "iss": "stackoverflow",
    "sub": "joe",
    "aud": ["all"],
    "iat": 1300819370,
    "exp": 1300819380,
    "jti": "3F2504E0-4F89-11D3-9A0C-0305E82C3301"
    "context": {
        "user": {
            "key": "joe",
            "displayName": "Joe Smith"
        },
        "roles":["admin","finaluser"]
    }
}

See alternatives here https://stackoverflow.com/a/37520125/6371459

Community
  • 1
  • 1
pedrofb
  • 37,271
  • 5
  • 94
  • 142
  • I'm trying to expand on #2: What to put in public claims. I don't think `email` and `address` are good examples because they *should* be configurable and without blacklisting the token, so the user doesn't have to login again from another device. However, properties such as `admin` or `scopes` would be good candidates for your blacklisting approach. I'm simply looking for other properties I could add to the token. – user1164937 Aug 11 '16 at 22:50
  • Additionally, you have to keep in mind that it should be as short as possible because it is mainly used in a web context. – Spomky-Labs Aug 12 '16 at 07:31
  • Check this link to get the actual registry of claims http://www.iana.org/assignments/jwt/jwt.xhtml. To build a blacklist you would need to use a unique ID for token in `jti`, or include an userID in `sub`. Using also `iss` you can control how to revoke only old tokens – pedrofb Aug 12 '16 at 08:16