1

Mobile devices aren't considered a confidential client, meaning it cannot store secrets. In the OAuth2 case, it means that refresh token and consumer secret should not be stored on the device. Hence, once the access token is expired it's impossible to refresh it and the user is requested to login again.

Is there a way to persist a long user session other then generating a long-lived access token? Isn't it bad practice to have a long-lived access token in the first place?

Community
  • 1
  • 1
Benny Bauer
  • 1,035
  • 1
  • 6
  • 19
  • I'd like to find an answer for this as well. [This post](https://alexbilbie.com/2013/09/securely-store-access-tokens-in-single-page-web-app/) suggests proxying all calls through a server-side script that can add the necessary tokens. But it's not clear to me how you would properly secure that script without a separate session, and that would seem to defeat the purpose of OAuth. – JW. Aug 25 '17 at 17:30

1 Answers1

0

It's a standard practice to store access and refresh tokens in a protected space on the device. On iOS, you should store them in the keychain. For more details on how to do this, see this answer:

Storing access token and refresh token in KeyChain

Community
  • 1
  • 1
Mathew Spolin
  • 371
  • 1
  • 11
  • Keychain can be read if phone is jailbroken or exploited. See [OWASP's Top 10 Mobile Risks](https://www.owasp.org/index.php/Mobile_Top_10_2014-M2) – Benny Bauer Mar 15 '16 at 19:55