Single Page Applications

Securing Single Page Apps using the OAuth2 Implicit Grant Flow

Use Case Description

Modern Single Page Applications are typically powered by a backend REST API, which needs to be secured against misuse. As the application lives entirely in the browser (user agent) of the end user, and does typically not have a server session, traditional approaches for this (server side sessions) are not desired.

In order to decouple the backend API and frontend application, an API Gateway can be put in place to implement the OAuth 2.0 Implicit Grant Flow or Authorization Code Grant with the PKCE extension, which is the recommended way of solving giving a "public" client (as opposed to a "confidential" client) access to an API.

 

Development Time Workflow

For development time, the following workflow is typical:

  1. The developer signs up for the API Portal and registers the single page application in the portal; the developer specifies exactly under which URL the SPA will be reachable from (tick the "OAuth 2.0 Redirect URI" check box for the application)
  2. By creating a subscription to the Backend API, the developer obtains client credentials for the single page application, a client ID and a client secret; for this use case, only the client ID is significant
  3. The developer incorporates the client ID into the single page application:
    • If the SPA does not have a valid access token (e.g. in the HTML5 local storage), redirect to the Authorization Server (the URL of which is stated on the API page in the API Portal), specifying which application is calling by passing on the client_id=... and response_type=code in the redirect parameters
    • Expect to get called back being passed an authorization code in the query parameter of the URL of your own application (e.g. `https://my.spa.com/?code=abc928987dffabe9273`)
    • Use an AJAX call to retrieve a token from the token endpoint

For the OAuth2.0 Implicit Flow Grant and the Authorization Code Grant, it is strongly adviced against to also incorporate the client secret into the single page app; this would enable attackers to reverse engineer the app and extract the credentials. The client ID helps the authorization server to know exactly to which URL it will deliver the access token.

wicked supports both Flows, but the Authorization Code Grant is the flow which is recommended, being more secure.

Runtime Workflow

To illustrate the runtime flow of such an authentication and authorization process using the OAuth 2.0 Implicit Flow Grant, see this picture:

Usually, the SPA will try to store an access token inside its local storage; in case there is none to use, or if it has expired, the SPA should redirect to the Authorization Server to get a new token or authorization code. Wicked supports "silent refreshes", which is the technique which is usually applied to refresh tokens in situations where refresh tokens do not exist.

When registering the application/client, you must specify that it's a Single Page Application (aka browser based application). This has certain effects on the Authorization Server, such as a refresh token is not being returned.

 

How do I implement this with wicked?

wicked.haufe.io has everything in the box to implement this type of workflow, using any identity provider you need, including wicked's own username/email and password store. Follow these steps:

  1. Using the wicked Kickstarter, specify which type of authentication you need (Google, Twitter, Github, SAML,...), by adding an authentication method to the default Authorization Server.
  2. Create an API defintion using the Kickstarter, and specify "OAuth 2.0" as a means of authentication and authorization. Link the authentication method you created previously to this API.
  3. Specify that you want to use the "Implicit Grant"/"Authorization Code Grant" on the API definition; - from an API perspective the two grants are behaving identical, it just opens up more possiblilies for the Application developer which one he wants to use, even thought the latter is the recommended flow.
  4. Deploy your updated API management configuration to your wicked instance.

Now application developers can sign up for using your API; the portal will help the developer to setup up the application and will also have help pages for the different flows (see Implicit Grant help page, and the Authorization Code Grant help page).

Back to top

© 2016-2018 Haufe-Lexware GmbH & Co. KG, www.haufe-lexware.com, www.haufe.de, www.lexware.de, www.haufe-akademie.de