2

As I understand the answers to this question JWT: Is refresh an expired token is a good strategy?, one should use a refresh token to refresh an expiring auth token.

Since my web app should be stateless and I cannot tell, whether the refresh token was revoked, there is no point in using a refresh token.

Instead I want to refresh the auth token simply by sending the users credentials again to obtain a new auth token. For this to work, the client has to store the credentials in memory, which might be an issue.

Are there any other ways to achieve this, or is the only secure way adding a list of revoked refresh tokens?

  • You may want to mention what 'JWT' means, as it's not a super common acronym. – Daisetsu Apr 24 '16 at 21:32
  • Just edited, it is JSON Web Token – Hendrik Apr 24 '16 at 21:42
2

The refresh mechanism is precisely built to avoid saving credentials. Credentials give you access to the whole account, whereas the refresh token only gives you access to auth tokens that will work for the designated domain.

You say you app is stateless, but if you can save credentials why can't you save a refresh token?
Besides, your app should handle expiration of the credentials as much as it should handle the expiration of the refresh token. Here are a few ways for credentials to expire:

  • User changed password
  • User lost right to run the app
  • Account was suspended
  • User changed username

So here is the basic design you should follow:

  1. Try communicate with your resource API using your auth token
  2. If 1. failed, try acquire an auth token with your refresh token
  3. If 2. failed, show login view to acquire a new refresh token

I suspect you are using OAuth. Respect the design pattern you're following, doing anything out of the pattern will put you at risks.

You could also offer your users the possibility to revoke a session (refresh token). That way, they can log out a compromised device without having to change their password. If you save the password, the only way to remotely log out a device is to change the password, hence logging out all you devices.

  • Thanks for your response, it is very helpful. I am not using OAuth, the rest api itself provides authentication mechanisms. It seems that it would be better to implement refresh tokens. How long are such refresh tokens usually valid, and what does it depend on? – Hendrik Apr 25 '16 at 9:33
  • Anything between 10 minutes and 10 thousand years. It's probably a settings of your authentication server and the information is contained in the JWT token (you can use jwt.io to see the value of the exp attribute). – Thibault D. Apr 25 '16 at 10:17
  • Yeah, but it is my API. What would be a typical value for a webapp, which will only be used irregular, for some minutes at max? – Hendrik Apr 25 '16 at 10:34
  • (It will be some sort of a password storage, thus the short average use time) – Hendrik Apr 25 '16 at 10:37
  • It depends how often you want your users to log in again and how it will affect them. Social networks have rather long-living (but revokable) sessions. Websites in relation with work usually have about a workingday-long session (8-10-12 hours?). In your case probably a few hours would be enough. – Thibault D. Apr 25 '16 at 11:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.