Single page applications (SPAs) have become the most popular way to create websites that feel faster for the end-user without hitting the server every time a user interacts with an application.
Shifting away from the traditional cookie-based approach, SPAs have no dedicated backend and instead use access tokens to call APIs on behalf of an authenticated user and return the relevant data. By ensuring that websites are highly responsive to end-user actions, SPAs have played a pivotal role in improving the customer experience. However, the shift from handling authorization with cookies to access tokens has severe security implications.
First and foremost, the frontend code operates in an insecure environment: a user’s browser. SPAs often possess a refresh token that grants offline access to a user’s resources and can obtain new access tokens without interaction from the user. As these credentials are readable by the SPA, they are vulnerable to cross-site scripting (XSS) attacks, which can have dangerous repercussions such as attackers gaining access to users’ personal data and functionalities not normally accessible through the user interface.
As the online data pool grows and hackers become more sophisticated, security must be taken seriously to protect customers’ information and businesses’ reputations. However, designing security solutions for SPAs is no easy feat. As well as the strongest browser security and simple and reliable code, software developers must consider how to deliver the best user experience – wrapping all this into a solution that can be deployed anywhere. The SPA’s web content can be deployed to many global locations via a Content Delivery Network (CDN). Web content is then close geographically to all users so that web downloads are faster.
The current best practice is for SPAs to protect tokens from malicious code. There are other ways to protect tokens, but using tokens in the browser is perceived as less secure. Protecting tokens can be achieved by adding a backend component to handle tokens and issue secure cookies to the frontend – often referred to as a Backend for Frontend (BFF) approach. Many developers use website stacks with a “web backend” that both serves static content and also writes secure cookies – which, in principle, solves the security problem. However, website stacks simply aren’t designed for the separation of web and API concerns that SPAs are characterized by.
The token handler pattern is a modern evolution of BFF, where OpenID Connect security is implemented in an API-driven manner. Using this approach, all communication from the SPA to the authorization server goes through the token handler. This eliminates the need for tokens to reach the SPA, with the token handler instead issuing session cookies to the SPA. The cookies are used during requests to APIs and are exchanged for an access token, preferably by a dedicated plugin in the API gateway, so that the API code is kept simple. As the token handler code is not available in the browser, it …….