Search code examples
react-nativeauthenticationauth0

Auth0: Specific questions about token storage and flow for mobile app

I’m building a react native app that will interact with APIs that I also write/manage. I have found Auth0 documentation for implementing this flow, but I’m not sure on where/when to save the tokens. I want to be sure I nail this step, because I feel like it has the potential to reduce the security of the flow by a great deal if I don’t do it correctly.

Here is the flow as I understand it (no error handling, only happy-path for sake of brevity):

  • A user enters the app for the first time, or is not already logged in
  • They log in using the Auth0 web-login-thingy
  • I receive a token
  • I can use the token to authenticate with my API

Questions:

  • Do I store that token? I don’t want my users to have to log in every time they use the app. If I do store the token, where do I store it?

  • If I’m not storing it, what do I do? Do I ping an authentication/authorization endpoint with Auth0 every time they open the app and get a new token?

  • Say I am storing the tokens, if I'm using the ID token for user data, should I be hitting the API again regularly to keep it up to date? Only when the user opens the app again? Not until they trigger a change in the app?

  • Instead of using the ID token for user data, should I just use that to get the user's ID and ping my database for user data?

I have the basics of this flow, and I'm able to sandbox it, but I want to start applying production-ready app logic to this flow and that's where I'm stuck. I’m a little lost here, so any help is good help.

Thanks!!

Solution

  • Here's a brief answer to your questions when using Auth0:

    1. Yes! you store it, the most secure way to store the token is in your device's local storage, that way it is not kept either in application's state or in a global variable.

    2&3. See above, but to add more information, you can configure your tokens to have an expiry length. in theory you would convert this 'expiry time from inception' to a date object, and can do one of two things; you can request a new token using the Refresh Token (that comes with the original) once the expiry has been reached, or force the user to re-log in and re issue a new token at this time (i prefer the latter, prevents people from just renewing their tokens forever as long as they remain logged in)

    1. Use the auth token to request user information after login, this can be stored in app state/global variables/wherever. You then want to use the auth token in the Authorization Header for each API call, along with whatever data you are sending. this ensures that even once someone is INSIDE the application, they need to have a valid token to actually do anything involving data (imagine someone back-dooring into your app and skipping the authorization, or using something like postman to just hammer your API with garbage). it would work something like this: GET userData { Header: auth token } -> GET userProfile (by sending your user ID returned from GET userData) PLUS {Header: auth token }

    I can give more in depth examples if you wish, and i apologize if i misunderstood any of the question and gave redundant/incorrect answers

    Edit: Resources about using secure storage for keys

    Document for when to use in-memory storage Vs persistent storage. The TL;DR is use in-memory if the key is expected to expire before a standard session duration, and persistent for storing a key between sessions https://hackernoon.com/mobile-api-security-techniques-682a5da4fe10

    link to Keychain Services doc https://developer.apple.com/documentation/security/keychain_services#//apple_ref/doc/uid/TP30000897-CH203-TP1

    link to SharedPreferences doc https://developer.android.com/reference/android/content/SharedPreferences.html