2

Do people typically store permissions in a JWT? I've seen example that might have admin: true or scopes: ['add_foo', 'delete_foo', 'read_foo']. And this seems fine, other that the potentially large size that the JWT could become if there are a lot of permissions/scopes. It seems like it would be really useful as you wouldn't need to hit a DB or cache to get the users permissions as long as the JWT can be verified.

My main question though is how these would be invalidated in the event of a permissions change.

For example, sys admin Joe, revokes the 'add_foo' and 'delete_foo' permissions from user Bob, but keeps the 'read_foo' permission. In this scenario user Bob should not have his token entirely invalidated and need to log back in, he should basically be forced to get a new JWT with the new permissions and carry on as normal.

I've seen examples explaining issuing a new JWT in the event of a password change, but the difference here is that sys admin Joe does the update to user Bob. Thus, there is no opportunity in this workflow for user Bob to get the new token immediately.

Most examples suggest for invalidation maintaining a black list of revoked tokens, or changing a DB record ID so the token is no longer valid, or having a per-user secret and changing that.

I see that all of these would work for the revoking of the token and test that its invalid, but how does the user then get a new token? their current JWT is now invalid? Trying to do anything with it should fail.

I've seen mention of a "refresh token". Are these widely use? Are they secure on the web or mainly used for mobile apps where the refresh token is harder to obtain. It seems like it would be reasonably easy to steal a refresh token via browser dev tools or similar and then someone would have access forever to that account until the unauthorized access was noticed and the refresh token revoked.

Maybe in this scenario forcing user Bob to re-authenticate is not such a big deal? Permissions probably don't change too often.

Thanks, Mike.

mleonard87
  • 324
  • 1
  • 11

2 Answers2

0

You can set expiration date (for Web app we are usually using 15 min - 30 min, for mobile 1 week). When you set Issued at claims parameter ("iat"). Then every time when you validate token you should check the token's "age". If it older than 5 min you load data from DB and create new token with current "iat" value.

Jan Pavtel
  • 678
  • 5
  • 8
0

When permissions change you should invalidate the issued tokens for this user. There are different techniques to use. See Invalidating client side JWT session

But consider that revoking tokens is not a recommended practice because you lose one of the main advantages of JWT: It does not require server storage.

The objective of Refresh tokens, as defined in Oauth2.0, is allow applications to obtain a new access token without re-authenticate

Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires,

If the permissions do not change frequently it may be easier to re-authenticate user, and if they change much consider whether they really should be included in the token

Community
  • 1
  • 1
pedrofb
  • 37,271
  • 5
  • 94
  • 142