We need to implement an authentication for users from one system to another. Previously we were using OAuth (user enters username/password and system get a temporary access key and a constant refresh key to refresh the access key), but now we have decided to improve security and stop using this system because the refresh key is constant. We are looking for a way that does not require the storage of any constant key to avoid a situation where somebody who steals the key and gets access to the system forever without us having a way to know about it and change the key.

A simple solution is to update the refresh key every defined period of time by requiring the user to login again. But our client wants users to log in only one time and shouldn't have more "problems" with authentication after that.

This situation seems mutually exclusive - the system should not have a constant key but should allow constant access. Is there any way to combine the two?

  • If a Refresh Token is compromised, it should be revoked. After that, you have to do the authorization process again to get a new Access Token and Refresh Token. Dec 12, 2017 at 12:47

2 Answers 2


It can't be done. The logged in used needs to prove they are the person that authenticated manually. To do that you need some kind of token. Look at it this way - what if the client machine was cloned? How would you be able to tell apart the real and the fake?

The only alternative is on expiry forcing the user to re-authenticate manually.


The only way to handle that is to provide for a way for the refresh token to be refreshed using itself as an authorization token.

It is, however, of dubious usefulness as a stolen token could be used to maintain permanent access.

Perhaps a more balanced approach would be to identify each token by device and provide a way for the user to revoke each token separately.

You must log in to answer this question.

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