How To Securely Implement Authentication in Single Page Applications

Exploring OAuth, OpenID Connect, and their common security pitfalls

Photo by Jantine Doornbos on Unsplash

In this piece, I will focus on authentication in single page applications. What’s the correct flow to use with OAuth and OpenID Connect (OIDC) and where are the security pitfalls when implementing it? After reading this piece you should be able to design the login for your new application correctly and know whether your current application is using OAuth/OIDC securely.

Please note: What’s correct for single-page applications is not necessarily true for other forms of applications like mobile applications or classic web applications (old school, boo!). Some concepts described here still hold for these types of applications, others might be wrong or even insecure. So, please be careful and always make sure you apply the right concepts to the right applications.

This will be the first in a series on this topic. Here, I would like to lay the foundations for understanding the necessary parts of OAuth and OIDC and outline the security considerations that lead to certain architectural decisions. In subsequent pieces, I will implement examples with different authorization server providers and discuss the differences between them.

Single Page Applications

Single page applications usually pack all their business logic in a JavaScript front end part written in React, Vue.js, Angular, or similar and load the necessary data from a back end API. In order to protect the back end data from unauthorized access, these applications require the user to authenticate via a separate authorization server and obtain a token after successfully logging in. This token can then be used when calling the back end where the API can verify the validity of the token and therefore the authenticity of the calling user.

Basic setup for single page applications

The authorization server can either be completely self-developed or self-hosted using an existing 3rd party solution like Keycloak. A third alternative would be using an authentication-as-a-service provider…