1

I am making Android app and API for it. I want to keep user logged in on the app until it logs out or reinstall the app etc. But I also want to secure API with JWT that will expire in let's say an hour.

My idea was, to keep username in the app storage after successfully logged in, and last JWT. Then when app is opened, it will communicate with API and even if the JWT is expired but 'valid' it will reissue new token. But is that secure solution? Or is there better solution for that ?

uneasy
  • 547
  • 1
  • 7
  • 17

2 Answers2

4

This is a classical use case of refresh tokens. The way the flow will work:

  • User logs in, the backend issues a short-lived (~1 hour) JWT and a long-lived refresh token and sends them to the frontend.

  • The frontend sends the JWT for each API call while it's still valid

  • In the event that the JWT has expired, the frontend should then use the refresh token to get a new JWT AND and new refresh token (rotating refresh token - see https://www.rfc-editor.org/rfc/rfc6749#section-10.4).

  • If the refresh token expires, then the user has to login again.

The advantage of the above method is that you can keep your APIs secure, and have the user be signed in for as long as you want.

Why do we need a refresh token (as opposed to using the invalid JWT to get a new one)?

  • Once a JWT expires, semantically, it should be completely useless.. if you allow it to be used to get a new JWT, then you haven't really expired it.

  • If an attacker gets hold of the JWT, after its expiry, then cannot continue to use it.

What if an attacker steals the refresh token?

This is where the charm of rotating refresh tokens comes into play. When you change the refresh token on each use (and revoke the older one), this allows you to 1) vastly minimise the risk from theft 2) detect that a theft has happened! And once you detect that, you can go about revoking the whole session to keep that user safe.

This and other benefits are explained in detail in this blog post

A note about the confusion of refresh tokens in other discussions

Lots of places state that you should not send the refresh token to the frontend. This is true in the case of an OAuth flow - where a third party is issuing tokens for your system's use. In this case, the "frontend" is your system (your app's frontend and backend) and the "backend" is the third party. I realise this may be a little confusing, but I am happy to chat about it here (My handle is @rp)

Final note

I would like to say that you can go ahead and implement this flow yourself (do take care of numerous race conditions and network failure issues mentioned in the above blog post), or you can check out and use our solution that does exactly (and much more) what is mentioned above in this answer.

I hope this helps!

Community
  • 1
  • 1
Rishabh Poddar
  • 919
  • 3
  • 9
  • 17
  • I do understand idea of refresh token, which it makes sense. But implementation of it makes me think ... So you say you can revoke refresh token, does that mean you have to store refresh tokens in database? How do you actually revoke refresh token on backend , and how do you even detect it has been stolen (some IP and salt combination in refresh token? ) ? Also, if refresh and access token is stored in client app, I guess they can both get stolen from there, unless refresh token only prevent getting token "on the fly" ? – uneasy Jan 27 '20 at 12:50
  • Revoking refresh token implies removing it from the database. The detection of theft is explained well here: https://medium.com/hackernoon/the-best-way-to-securely-manage-user-sessions-91f27eeef460. This link also answers your last question in the comment. – Rishabh Poddar Jan 27 '20 at 13:08
  • 1
    Thank you, I found security subject really interesting and that's why I am trying to understand it as much as I can. I think I get the idea now. Now is time to finally start implementing it. Thank you – uneasy Jan 27 '20 at 13:54
  • Ok, I started implementing that in my project. However, can I use same api for issuing access and refresh token, or its a bad practice? How to validate refresh token? For now I use token plus username provided in request body, and if that pair exists in database and token is not revoked it will issue access token. Is that fine? – uneasy Jan 27 '20 at 18:16
  • I'm not sure what you mean by using same API for issuing access and refresh token. The other questions you are asking are quite open-ended. So, either chat with me on discord: supertokens.io/discord (@rp is my handle). Or, you can use SuperTokens (https://supertokens.io) in your project and not reinvent the wheel :) – Rishabh Poddar Jan 28 '20 at 11:32
0

JWT is the only needed storage on client side. The username can be part of the claims (or payload).

Refresh tokens carry the information necessary to get a new access token. In other words, whenever an access token is required to access a specific resource, a client may use a refresh token to get a new access token issued by the authentication server. -- Sebastian Peyrott

You only need to correctly validate the token's claim and then you'll be ready to read the refresh token, the username and every other information.

Take a look at this question where they explain how to use the access token.

MarAvFe
  • 468
  • 4
  • 15
  • Ah I forgot about refresh token. Yes I know I can have all data I need in the token itself. I don't really understand idea of refresh token. Why is it different from sending expired but valid token and sending new one back after validation? – uneasy Jan 26 '20 at 19:46
  • Looking for it, there's a debate on whether it is a good idea or no. Take a look at this thread https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/#comment-2822257684 and http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ – MarAvFe Jan 26 '20 at 20:00
  • That just gives me more questions than answers ;), I do get idea of refresh token now, and why I could use it. However in my case, I don't really want to check/keep session as such. Once user is logged in, he will be logged in until he logs out, or changes device. But in the same time, I want to keep API secured. I am thinking, because I will be keeping push notification token for a device as well, maybe I could make a pair of token and device id (push token) when calling the api, and based on that check access to api ? but in the other hand I don't want to poke database each api call .. – uneasy Jan 27 '20 at 07:13