Why do access tokens expire

Question

I am just getting started working with Google API and OAuth2  When the client authorizes my app I am given a  refresh token  and a short lived  access token   Now every time the access token expires  I can POST my refresh token to Google and they will give me a new access token   My question is what is the purpose of the access token expiring  Why can t there just be a long lasting access token instead of the refresh token   Also  does the refresh token expire   See Using OAuth 2 0 to Access Google APIs for more info on Google OAuth2 workflow

User · Answer

It is essentially a security measure  If your app is compromised  the attacker will only have access to the short-lived access token and no way to generate a new one   Refresh tokens also expire but they are supposed to live much longer than the access token

User · Answer

In addition to the other responses   Once obtained  Access Tokens are typically sent along with every request from Clients to protected Resource Servers  This induce a risk for access token stealing and replay  assuming of course that access tokens are of type  Bearer   as defined in the initial RFC6750     Examples of those risks  in real life    Resource Servers generally are distributed application servers and typically have lower security levels compared to Authorization Servers  lower SSL TLS config  less hardening  etc    Authorization Servers on the other hand are usually considered as critical Security infrastructure and are subject to more severe hardening  Access Tokens may show up in HTTP traces  logs  etc  that are collected legitimately for diagnostic purposes on the Resource Servers or clients  Those traces can be exchanged over public or semi-public places  bug tracers  service-desk  etc    Backend RS applications can be outsourced to more or less trustworthy third-parties    The Refresh Token  on the other hand  is typically transmitted only twice over the wires  and always between the client and the Authorization Server  once when obtained by client  and once when used by client during refresh  effectively  expiring  the previous refresh token   This is a drastically limited opportunity for interception and replay    Last thought  Refresh Tokens offer very little protection  if any  against compromised clients

User · Answer

This is very much implementation specific  but the general idea is to allow providers to issue short term access tokens with long term refresh tokens  Why    Many providers support bearer tokens which are very weak security-wise  By making them short-lived and requiring refresh  they limit the time an attacker can abuse a stolen token  Large scale deployment don t want to perform a database lookup every API call  so instead they issue self-encoded access token which can be verified by decryption  However  this also means there is no way to revoke these tokens so they are issued for a short time and must be refreshed  The refresh token requires client authentication which makes it stronger  Unlike the above access tokens  it is usually implemented with a database lookup

User · Answer

A couple of scenarios might help illustrate the purpose of access and refresh tokens and the engineering trade-offs in designing an oauth2  or any other auth  system   Web app scenario  In the web app scenario you have a couple of options    if you have your own session management  store both the access token and refresh token against your session id in session state on your session state service  When a page is requested by the user that requires you to access the resource use the access token and if the access token has expired use the refresh token to get the new one    Let s imagine that someone manages to hijack your session  The only thing that is possible is to request your pages     if you don t have session management  put the access token in a cookie and use that as a session  Then  whenever the user requests pages from your web server send up the access token  Your app server could refresh the access token if need be     Comparing 1 and 2   In 1  access token and refresh token only travel over the wire on the way between the authorzation server  google in your case  and your app server  This would be done on a secure channel  A hacker could hijack the session but they would only be able to interact with your web app  In 2  the hacker could take the access token away and form their own requests to the resources that the user has granted access to  Even if the hacker gets a hold of the access token they will only have a short window in which they can access the resources   Either way the refresh token and clientid secret are only known to the server making it impossible from the web browser to obtain long term access   Let s imagine you are implementing oauth2 and set a long timeout on the access token   In 1  There s not much difference here between a short and long access token since it s hidden in the app server  In 2  someone could get the access token in the browser and then use it to directly access the user s resources for a long time    Mobile scenario  On the mobile  there are a couple of scenarios that I know of    Store clientid secret on the device and have the device orchestrate obtaining access to the user s resources  Use a backend app server to hold the clientid secret and have it do the orchestration  Use the access token as a kind of session key and pass it between the client and the app server     Comparing 1 and 2  In 1  Once you have clientid secret on the device they aren t secret any more  Anyone can decompile and then start acting as though they are you  with the permission of the user of course  The access token and refresh token are also in memory and could be accessed on a compromised device which means someone could act as your app without the user giving their credentials  In this scenario the length of the access token makes no difference to the hackability since refresh token is in the same place as access token  In 2  the clientid secret nor the refresh token are compromised  Here the length of the access token expiry determines how long a hacker could access the users resources  should they get hold of it   Expiry lengths  Here it depends upon what you re securing with your auth system as to how long your access token expiry should be  If it s something particularly valuable to the user it should be short  Something less valuable  it can be longer   Some people like google don t expire the refresh token  Some like stackflow do  The decision on the expiry is a trade-off between user ease and security  The length of the refresh token is related to the user return length  i e  set the refresh to how often the user returns to your app  If the refresh token doesn t expire the only way they are revoked is with an explicit revoke  Normally  a log on wouldn t revoke    Hope that rather length post is useful

[oauth] Why do access tokens expire?

Examples related to oauth

Examples related to oauth-2.0

Examples related to google-api

Examples related to google-oauth