title: Do OAuth2 access tokens for a mobile app have to expire?
body: <p>The accepted answer here as to <a href="https://stackoverflow.com/a/7035926/14955">why OAuth2 access tokens expire</a>: </p>
  
  <ul>
  <li>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. (<strong>What does this mean? I take it to mean allow transmission without TLS? Anything else?</strong>).</li>
  <li>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.</li>
  <li>The refresh token requires client authentication which makes it stronger. Unlike the above access tokens, it is usually implemented with a database lookup.</li>
  </ul>
  
  <p>Assuming that we don't support non-encrypted transmission of the access token takes care of the first bullet point.</p>
  
  <p>Assuming that we are fine with doing a database lookup against a revokable, completely random access token takes care of the second one.</p>
  
  <p>For mobile apps, client authentication cannot be stronger, because "the client_id and client_secret obtained during registration are embedded in the source code of your application. In this context, the client_secret is obviously not treated as a secret." (<a href="https://developers.google.com/accounts/docs/OAuth2InstalledApp" rel="noreferrer">Google</a>). That eliminates the third concern.</p>
  
  <p>So what is the benefit of separating short-lived access tokens and long-lived refresh tokens in this scenario? Is it "okay" to just issue non-expiring access tokens and ignore the whole refresh token part?</p>