2

Quick question about the json web token.

When my token is expired, I get a refresh token based on my current token (without validating the current user).

So what would happen when I changed the permissions from a user, and he isn't allowed to get data from the web api anymore? Should I store the jwt in the DB so I can validate his permissions or what?

And I have read that a token is splitted up in 3 parts with some user information in it. How can a refresh token be different if it sould carry the same information?

I really hope somebody can help me out with this one.

Grtz, Robin

Robin Verhagen
  • 45
  • 6

1 Answers1

3

So what would happen when I changed the permissions from a user, and he isn't allowed to get data from the web api anymore?

You should invalidate the token

Should I store the jwt in the DB so I can validate his permissions or what?

It is not an easy question with several alternatives. See Invalidating client side JWT session

1) Remove the client token

2) Token blacklist: Store tokens that were between logout & expiry time, mark expired and check it in every request. Requires server storage

3) sign the token with a hash of their password or permissions summary. If signed field changes, any previous tokens automatically fail to verify. Extend this mechanism with other field of interest to sign. The downside is that it requires access to the database

How can a refresh token be different if it sould carry the same information?

The first part is the header of the token (signature algorithm), the second part is the payload (subject, name, issuer, issue time, expiration, etc), the third part is the signature, which is performed over the header and payload. Since data like 'issue time' will be different, the signature field will change

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