3

The scenario is: you have refresh token that is valid for a longer period of time and an access token that is valid for a shorter period of time.

The setup: There is a client, application server and authentication server.

  • The client stores the access token.
  • The application server stores the refresh token.
  • The authentication server hands out the refresh + access token.

One of the advantages is that a stolen access token can only be used for the time it is valid.

Say a hacker steals the access token that is valid for 30 minutes. When the hacker makes a request with the valid but expired stolen access token after 30 minutes, the application server refreshes it with the refresh token, thus the hacker gaining a new valid and not expired access token.

How can this be prevented?

  • one way that it could be done is use a php session and store an alpha numeric generated character in a session variable then combine the token and this session variable together as one string, then MD5hash it then store that in a db table. then on token check, it takes the token then combines it with the current session variable then that is md5 hashed, then the two strings are compared. if different, then its a stolen or bad token. If a match, continue the code to renew the token. – drtechno May 11 '18 at 17:37
  • this should be a good way since 1/2 of the "key" is only stored temporarily in the client machine's memory. – drtechno May 11 '18 at 17:41
2

To get a new access token, the client needs to send the refresh token to the server. So if the attacker only steals the access token, she will not be able to refresh. To do that, she needs to steal the refresh token as well. Now, if the attacker is in a position to steal the access token she can probably snatch the refresh token as well while she's at it. So maybe this doesn't make a lot of difference for the token theft scenario, but I still wanted to point it out.

Dividing it up into one access and one refresh token does not protect against theft. That is not what it is designed for. The purpose of the division is to make it possible for the server to revoke tokens without having to hit the database on each single request.

So how do you protect against theft? Same way you would do with any client side secret, be it a session ID or what not. Set a limited lifetime (of the refresh token, in this case), use good TLS, and perhaps include some geolocation information in the token so you can block requests that suddenly comes from the other side of the planet.

  • 1
    Thanks! There is a client, application server and authentication server. The client store the access token. The application server stores the refresh token. The authentication server hands out refresh + access tokens. So if I understand it correctly we can't prevent a refresh of a stolen access token without any fingerprinting. To protect against theft we have to link an access token with User-Agent, IP address etc., correct? – Arthur May 11 '18 at 9:31
  • @Arthur Oh, sorry, missed that this was OAuth and an authentication server is involved as well. Not sure if this answer is correct anyore, there might be some way to deal with this, but I am not so familiar with this kind of setup. Might delete this answer since it's not really fitting the question. – Anders May 11 '18 at 9:42

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.