4 Accessing a secured microservice via a single-page application

In chapter 2, we discussed how to secure a microservice with OAuth 2.0 and directly invoked it with a curl client. Chapter 3 made further improvements by deploying the microservice behind an API gateway. The API gateway took over the OAuth 2.0 token validation responsibility from the microservice, and the communication between the API gateway and the microservice was secured with mTLS. The API gateway introduced a layer of abstraction between the client applications and microservices. All the communications with microservices had to go through the API gateway.

In this chapter, we discuss in detail how to build a single-page application, or SPA (pronounced spä), to invoke microservices via an API gateway. In case you’re wondering why we’re talking about building a SPA in a microservices security book, the reason is that understanding the constructs of a SPA is important in building an end-to-end security design. We believe in completing an end-to-end architecture with a microservices deployment, from data to screen. And SPAs are the most used client application type. If you are new to SPA architecture, we recommend you go through appendix C first. It will help you understand what a SPA is and the benefits it offers.

4.1 Running a single-page application with Angular

4.1.1 Building and running an Angular application from the source code

4.1.2 Looking behind the scenes of a single-page application

4.2 Setting up cross-origin resource sharing

4.2.1 Using the same-origin policy

4.2.2 Using cross-origin resource sharing

4.2.3 Inspecting the source that allows cross-origin requests

4.2.4 Proxying the resource server with an API gateway

4.3 Securing a SPA with OpenID Connect

4.3.1 Understanding the OpenID Connect login flow

4.3.2 Inspecting the code of the applications

4.4 Using federated authentication

4.4.1 Multiple trust domains

4.4.2 Building trust between domains

Summary