What are refresh tokens?

Refresh tokens can be used by client to get fresh access tokens from auth server for accessing the resource server. While access tokens are typically short lived refresh tokens are 

• Long lived
• They can be blacklisted by auth server . (signed jwt access tokens cannot be black listed by auth server as they can be read by resource server (after verification ) therefore check against authorization server introspection endpoint is not required )

Typically refresh tokens would be used when the application user should stay logged in for longer durations.

Why not have long lived access tokens which can be blacklisted by auth server ?

In the scenario that we do not want the user to re authenticate again and again, instead of long lived refresh token why not simply have long lived access token?

The reason is that long lived self contained access tokens cannot be blacklisted. long lived opaque access tokens can be blacklisted but this increases load on authorization server.

Here is how refresh tokens can actually improve both performance and security . 

• How performance is improved. Access tokens can be opaque or signed tokens depending on implementation. When resource server receives an opaque token , it must check with auth server for token info/validity /expiry etc as the token is opaque , it does not hold any information, it is the authoization server which holds information related to validity of access token . These cetralized checks of opaque access tokens 
  • • increases the load on auth server
    • increases latency for client as well .
    • makes auth server the single point of failure
    • makes the authorizatin server stateful as the access token itself does not carry any information.
    • token revocation how ever is easy as every hit from client to resource server is leading to a hit to auth server.
  •  
  •  For this reason many implementations use signed self contained access tokens which the resource server can introspect by itself. (after signature validation by the public certificate of the authorization server) and decide if the token is active (using exp attribute) user is authorized or not. No checks against auth server are needed.
    • this eliminates auth server as single point of failure
    • reduces load on authserver
    • reduces latency for client
    • But the problem in this approach is that signed  self contained access tokens cannot be black listed by auth server as the resource server does not even contact the authorization server introspection end point as the signed tokens are self contained and self verifiable.
  •  
  • For this reason, signed access tokens cannot be long lived. Then how do we ensure that user does not have to reauthenticate frequently .The solution would be,  have a signed short lived access token and long lived refresh token.  The refresh token will be used to fetch new access token from auth server only when the access token is expired hence reducing load on auth server and also reduces latency. Refresh tokens are opaque.Note that to get fresh access token client must go to auth server and hence the auth server can black list refresh tokens .
  •  
  • Note that refresh tokens have the down side that that
    • Once the refresh token is black listed  the revocation of access may not be immediate
    • Client coding logic is also more complicated.

• • Without refresh token
    • 1. Make api request with access token
    • 2. If access token is invalid , fail and ask user to reauthenticate.
  •  
  • With refresh token.
    • 1. make api request with access token
    • 2. If token invalid try to update using refresh token.
    • 3. if refresh request successful , update access token and make fresh api request to resource server with updated access token.
    • 4. if refresh request fails (as the refresh token is black listed or expired) then ask the user to reauthenticate.

• How security is improved.
  • If an access token is lost then it can be directly used to access resource server api , but if refresh tokens is lost it cannot be be used to get new access token without knowing client_id and client secret.
  • The refresh token is sent to auth server  at a lesser frequency , where as access token is sent to resouce server at a higher frequency.
    • Auth server are coded with great emphasis on security so chances of refresh token loss from auth server is lower than access token loss from resource server. (the tokens may get logged insecurly in some log file etc)
    • Lesser frequency of use of refresh token also means a smaller attack surface. (higher frequency helps an attacker)
  • Also since refresh tokens have longer life as compared to access token , they must be stored more securely by client app.

What are the other uses of refresh tokens?

Refresh tokens can be used for creating sliding sessions. Sliding sessions are are sessions which expire after a period of inactivity.