I considered using JWT for my REST-APi. The user should login at /api/login with basic auth and retrieves a JWT which is used for further requsts. At the beginning it was planned to have a very long life time for the token.

Now there are two problems: 1. the JWT should be blacklisted/invalidated 2. the roles of the user may change. The token should not send old roles.

So the solution is to use JWTs that expire early. But seriously, if I have to login at /api/login everytime, why don't I use basic auth for everything?

Of course I could also code a background service for the device that refreshes the token every few minutes using the old token. But what if the REST service or client is down of an hour? Everyone would be logged out. Also I do not want a background job which always refreshes tokens, even if the App is detached.

So I will end up with a database query that fetches the roles of the user and also checks if the JWT is not blacklisted at every request. Will there be any difference to the use of normal API keys then?

1 Answer 1


JWTs are self describing bearer tokens. You experience the two problems described (stale tokens, invalidation), because JWTs are not designed for this use-case.

I suggest you stick with API keys and store expiry and roles on the backend. It is simple and effective.

If you start blacklisting and querying roles with JWT you will end up in the same place with more complexity.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .