How to invalidinput JWT tokens?

Faced, at first glance, not a difficult task. Namely, how to invalidinput token? For example, if a user does a logout or change your password.

Shortly about the task: have a normal REST API, which is part of the functionality requires that the user is authorized. Implement it using JWT.

Searching the answer online found a few ideas on this score:
  • On the client to "forget" the token
    This is the simplest solution, but really the token it continues to work until then, until it expires life. So this solution is not very safe.

  • Storing in the database a blacklist with tokens
    If the user invalidates the token, we store it in the database. And on each request check whether the passed token in the black list. And, of course, clean the base on the expire.
    It is a viable option, but it partially defeats the purpose of the JWT.

  • Change secret
    Convenient option when you need to invalidinput tokens for all users. But if you do individual secret for each user, it must be stored somewhere (the DB again?) and you can't use a more robust algorithm is RS256. By the way, additional question - does it make sense to use it for web tokens?

Honestly, none of the variants I have found I don't think a full solution. There is a feeling that I missed something. I will be glad to hear any thoughts and advice on this.
September 4th 19 at 16:11
1 answer
September 4th 19 at 16:13
To do this, try and use fast storage, not the database (Ala radish). The radishes stored secret key for the token (each token its own). If the exit updates the key. And of course forget on the client.

The radish entry form
user_id : secret

According to this scheme and all work.
Thanks for the reply. Actually while this option I chose the only one really working.

What do you think about the following schemes of work:
1. When authorization is issued with the access_token malenikii TTL (say 5-10 minutes) and refresh_token. To store in my database will only refresh tokens.
2. Every 5-10 minutes, user will receive a request to update both tokens. It will not create a special burden and eliminate the need to check the token every user request (JWT action).
3. If a user does a logout on the client forget both the token and the server reset the refresh token in the database.

How secure is this scheme and what can be pitfalls in it? - Osvaldo.Dare commented on September 4th 19 at 16:16
it all crutches. And exit in 1st place we go out from all of your devices (theft of the token is not terrible). Now think of protection against theft in your version. To do as simple as possible. - Brody_Dickins commented on September 4th 19 at 16:19
: Then it turns sense of not of the JWT. In fact it is the implementation of a conventional token if each query through the database to check. This is the first. And secondly, how then to implement this approach in microservices architecture or when the service authorization of the individual, and several projects to work through it? In this case, we get a huge overhead to each request. - Osvaldo.Dare commented on September 4th 19 at 16:22
: I was once like you. Tortured jwt and realized that it is better to make a token. Well, usually between muzzle and microservices is a gateway which checks the authorization, and so on. Read from cover to cover - Brody_Dickins commented on September 4th 19 at 16:25
: Maybe I'm too idealistic) API Gateway in most cases is always there. But architectural should be a separate micro service responsible for the authorisation. API Gateway must contain a minimum of logic, and ideally just proxying requests. And in this case we each time we will wait until we answer a micro service authorization. I reported this overide meant. - Osvaldo.Dare commented on September 4th 19 at 16:28
Is it a joke or what? Horror. Firstly we don't know what user bound token, while we have not deciphered. So to store user_id:secret is nonsense. The question arises what to keep? The token? To have a separate database which stores all sekuruwe information? And if we lose her? Don't know who is running, but it's brutal - nikita.Stracke commented on September 4th 19 at 16:31
: I don't see what the problem is. When it comes to request token we will be validated. And the data in the token are stored in unencrypted form. User_id so we can get very easily and we need to once again not to yank the database. The tokens we need to store so that we could check refresh_token. If we lose her, then users will just have to re-login, which is not so scary.

> Don't know who is running, but it is a gesture
I'm not sure that you fully understand in JWT. But in any case I'll be glad to hear your ideas and suggestions. - Osvaldo.Dare commented on September 4th 19 at 16:34
I'm not sure that you fully understand in JWT. But in any case I'll be glad to hear your ideas and suggestions.

If over securnet is not required or if it is only API for gamers, Yes, the requests are passed via ssl, then not to bother, and to make a long-lived token (e.g. a year) that when sign out is removed from the client. Oh and to add a blacklist for features Ala "terminate all sessions" if the client thinks the token is compromised. This will be enough. - nikita.Stracke commented on September 4th 19 at 16:37
: Then it turns out ordinary tokens, not JWT. And all the benefits are lost. To make a long-lived token makes no sense, because we have a refresh_token which is long-lived. But the API will be carried out using an access_token with a short life span.

Blacklist also essentially unnecessary. After all, the idea I wanted to get rid of unnecessary database queries. Fast KV-store does not count, interesting more the opportunity to get rid of the extra queries. If the token is compromised, we can invalidinput refresh_token. After which it will be impossible to get a new access_token without login again. But for the old access_token will have to wait until he "dies." - Osvaldo.Dare commented on September 4th 19 at 16:40
: why lose? the main advantage of the jwt is that it is self-contained and we don't have to query the database on every request. the refresh token is like one of the technologies is not a standard, it's always at your discretion. Personally, I believe with refresh tokens is not like it is in many cases meaningless, greatly complicates the client and server code and adds useless junk over psuedoscience.

Even without blacklist you did not do. How are you going to invalidinput refresh token? To do exactly the same query in the database.

My suggestion is that in most applications it will be sufficient to erase the token from the client and everything. And as additional securest the blacklist in the radish for exceptional cases (like complete all sessions), which will work almost instantly. - nikita.Stracke commented on September 4th 19 at 16:43
if you have a database of secret keys that you request access to this database, meaning the jwt lost the same session. - trenton_Waelchi commented on September 4th 19 at 16:46

Find more questions by tags JSON Web TokenRESTful APIJavaScriptAPI