SPA High Level Requirements

Background

The Home Page described our overall goals and we will start by focusing on the main requirements for our Single Page Applications and APIs.

Standard OAuth Flow for an SPA

The Auth0 Web Site has an easy to follow diagram on which OAuth solution we should use, and we will use the Implicit Grant (or ‘Flow’):

Goal: Global Web Performance

If your SPA will be an Internet Web UI delivered to high profile users, then one of your big concerns will be Global User Performance.

The biggest performance bottleneck is typically the latency involved in the download of web resources. Use of a Third Party Content Delivery Network is the standard solution to this issue:

If your Web App’s Server Side is only Static Content (HTML / JS / CSS / Images), and does not need securing, then a CDN is much easier to enable:

API hosting has different characteristics and you may opt for a different solution with fewer global locations, for these reasons:

  • APIs expose sensitive data, which may affect where you host
  • APIs are typically backed by a database cluster
  • Latency during API calls is less of a performance issue

Goal: Best Usability

A key Usability Benefit of the Implicit Flow is that the SPA can actively decide when to redirect the End User to log in, and can restore state afterwards:

  • https://web.mycompany.com/#customer=5&order=13

Older Single Sign On solutions for ‘Web Apps’ return secured HTML views using cookies, then trigger Login Redirects server side.

This is not what we want to do in an SPA, since we want the UI to be in control, and to avoid issues such as losing the SPA hash location.

Goal: Cookieless for Simpler Security

When a Web UI uses authentication cookies, the browser sends it to the server implicitly., and most browsers make this cookie available in all tabs.

This means a malicious Web UI will automatically present the cookie – and you need to write code to protect against Cross Site Request Forgery attacks.

When using access tokens, they are only ever explicitly sent to our API, so we are in control of security. There are of course security risks with tokens, but they are fewer and we will use a library that deals with them for us.

Goal: Use Third Party Security Libraries

One of my key objectives will be to write as little security code as possible, and my current thinking is to:

  • Plug an Implicit Flow Security library into my SPA
  • Plug a Server Side Security Library into my API

This will help ensure we minimize security mistakes, and that we can take library updates for free when new features are delivered.

Implicit Flow Limitations

The implicit flow basically works as follows, where the UI redirects the user to login via an Authorization Server + Identity Provider, then receives an access token with which APIs can be called:

The biggest limitation of the Implicit Flow is that you cannot silently renew Access Tokens using Refresh Tokens, since the latter cannot be securely stored in a browser.

UI Scenario OAuth Token Renewal Mechanism
SPA Unofficial solution only (session cookies)
Other UIs Refresh Tokens

In addition, the Implicit Flow results in Greater Complexity in Javascript code, since cryptographic validation of received tokens is needed.

Our SPA Requirements

Here is a summary of this blog’s requirements, though obviously your company priorities could be a little different:

  • Good Global Performance via Web Content Delivery
  • Best SPA Usability for End Users
  • Short Lived Access Tokens with Silent Token Renewal
  • Our solution must Pass Security Reviews
  • We want to avoid writing any Complex Security Code

Where Are We?

We have clarified what we want from our SPA and API solution. Next we will dive into the OAuth Implicit Flow via a Code Sample.

Next Steps