0

according to this article http://www.jianshu.com/p/b11accc40ba7 one method to secure the JWT is refreshToken:

in center auth server, we maintain a table like this:

table auth_tokens(
    user_id,
    jwt_hash,
    expire
)

The following is work flow:

User request the login API with phone and we verified it, after that, the auth server send one token, and register the token ( add one row in the table. )

When the token expired, user request the exchange API with the old token. Firstly the auth server validate the old token as normal except expire checking, then create the token hash value, then lookup above table by user id:

  • a. If found record and user_id and jwt_hash is match, then issue new token and update the table.

    b. If found record, but user_id and jwt_hash is not match , it means someone has use the token exchanged new token before. The token be hacked, delete records by user_id and response with alert information.

    c. if not found record, user need login again or only input password. when use changed the password or login out, delete record by user id.

To use token continuously ,both legal user and hacker need exchange new token continuously, but only one can success, when one fail, both need login again at next exchange time.

So if hacker got the token, it can be used short time, but can't exchange new one if legal user exchanged new one next time, because the token valid period is short, it is more security.

If there is no hacker, normal user also need exchange new token periodically ,such as every 30 minutes, this is just like login automatically. The extra load is not high and we can adjust expire time for our application.

but imagine this senario:

For example, a hacker got the Bob's token, and he knows Bob is sleep at 1:00 am to 6:00 am, So, the hacker can use the toke at night continuously until Bob get up next day and use the application.

one solution is at the night, user should enter user and pass instead of token but this is not good solution in my idea! do you know better solution?

Thanks in advance

hossein derakhshan
  • 771
  • 2
  • 10
  • 23

1 Answers1

0

This solution is full of drawbacks and few advantages:

  • require server storage. You loose JWT statelessness. Even for token that never are going to be revoked

  • tokens, in fact, can be used for ever just refreshing with the old one

  • one token per user means one and only one device using the API. For example a login on a mobile device would invalidate a session in a desktop browser

  • an attacker could use a token while the user is sleeping ( as you pointed)

Then, the advantages: you can revoke a token. If you really need it ( it is recommended for JWT let tokens expire) I believe there are easy ways to implement it. See Invalidating client side JWT session

Note that you question started talking about "refresh" tokens, but later you have described a custom mechanism to refresh and revoke which has nothing to do. A refresh token is long lived, persistent an is used only to obtain short lived access tokens

pedrofb
  • 37,271
  • 5
  • 94
  • 142
  • thanks for your response. so how refresh token works? what is the best practice for implement a refresh token? – hossein derakhshan Sep 07 '17 at 05:35
  • You can read this article https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/ and this thread about refresh&access tokens defined in oauth2 protocol https://stackoverflow.com/questions/3487991/why-does-oauth-v2-have-both-access-and-refresh-tokens – pedrofb Sep 07 '17 at 06:28
  • @pedrodb thanks i read both links and change my question's ttitle. i understand we need server storage for having black list users. could you read this question? https://stackoverflow.com/questions/46093214/authentication-in-react-native – hossein derakhshan Sep 08 '17 at 07:17
  • Yes, it is. To maintain a blacklist it is needed to store in server side the revoked tokens (or just the unique identifier `jti` or last issue date) until expiration time. I will take a look to your new question. Do you need some additional clarification regarding this question? – pedrofb Sep 08 '17 at 13:12