User Sessions and Token Renewal

Background

In our last post we explained an Improved Code Sample with UI and API Claims Handling, but we are still missing essential features.

User Session Times for Your Company?

We will usually want to separate the User Session Time from the Access Token Lifetime, so that behavior is good from both Usability and Security viewpoints. This blog will use the following values:

UI Type User Session Time Access Token Lifetime
Web UI 12 hours 30 minutes
Mobile UI 1 week 30 minutes

Okta Settings

In Okta we can set times such as the above under API / Authorization Servers / Default / Access Policies / Default Policy Rule:

SPA Token Renewal can be a Blocking Issue

In our SPA Requirements we pointed out that there is no standard Implicit Flow solution for silently renewing Access Tokens.

Currently the user’s browser gets redirected to get a new access token every 30 minutes. From a usability viewpoint this is not Production Ready.

Implicit Flow and Session Cookies

Fortunately, Authorization Servers commonly issue Session Cookies that enable Silent Access Token Renewal.

In Okta the Session Cookie time is configured against our application, under Applications / Basic SPA / Sign On / Add Rule:

Token Renewal Mechanism

One option might be to make an Ajax request to the OAuth Authorization Endpoint, which would send the session cookie and get back a token:

However, browser CORS restrictions will prevent an Ajax client from reading Response Location headers or following the 302 redirect.

It turns out that the only option that works is to spin up a hidden iframe and redirect the user, so that the browser itself follows redirects.

IFrame Redirects

During the OAuth redirect we can set a ‘prompt=none‘ query parameter to ensure that the renewal request never gets routed to a Login Page:

The response will either be a new access token or a ‘login_required‘ error. The latter response indicates that the user’s session has expired, and that a new user login on the main window is needed:

Same Origin Restrictions

If your renewal redirect does not use prompt=none, you will sometimes be routed to log in. Almost all Login Pages will block requests on an iframe due to an X-Frame-Options header, which is best practice for vendor software:

IFrame Redirects and Code Complexity

We now have a solution for our Session Management requirements. It is easy to set the iframe redirect URL but these aspects remain difficult:

  • We need to manage iframe page execution in our SPA
  • We need to prevent noticeable delays for end users
  • We need to handle responses and update tokens in HTML5 storage
  • We need to handle login_required responses on the iframe
  • We need to handle errors and report them on the main window
  • We need to deal with blocked / timed out requests

OIDC Client and Token Renewal

Fortunately for us the OIDC Client library has a tested solution for token renewal, which does most of the above work for us, and which we look at shortly.

Where Are We?

We now have a better understanding of how the overall User Session will work for our SPA and we know what we want to implement.

Next Steps

  • We will continue with the theme of Session Management and discuss our Logout requirements
  • For subsequent samples and a list of all blog posts see the Index Page