Access Token Renewal


  • Browsers use non-expiring Test Tokens; Devices use expiring tokens that get renewed as long as the renewal token is present.
  • Considering expanding the information exchanged as part of the Access/Registration State API (Check Registration API)
  • Renewal Token is held under Secure Storage (FEC-10 has notes:
  • Browsers for Dev and BDD will use a configured test token that maps to test accounts. (Postman too).
  • Devices will be steered toward one of three cases:
    1. Registration workflow involving user interaction.
    2. Renewal workflow happening behind the scenes, but requires interaction with Application API, 3rd-party Auth, Secure Storage and Token Storage.
    3. Normal workflow with an Access Token providing access to the Application API.

Some Issues

  • Navigation Flow isn't clear from this diagram.
  • The Navigation Flow doesn't include confirmation and circling back in case the user wants to choose a different account.
  • Life-cycle needs a little more exploration:
    • What determines whether a session is established or not? At what time do we make sure our Access Token is valid for a length of time sufficient to avoid a renewal mid-outing?


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License