{"id":689908,"date":"2025-08-07T10:49:04","date_gmt":"2025-08-07T08:49:04","guid":{"rendered":"https:\/\/www.devoteam.com\/expert-view\/every-frontend-needs-its-backend\/"},"modified":"2025-08-07T10:49:04","modified_gmt":"2025-08-07T08:49:04","slug":"every-frontend-needs-its-backend","status":"publish","type":"expert-view","link":"https:\/\/devoteam.info\/me\/expert-view\/every-frontend-needs-its-backend\/","title":{"rendered":"Every Frontend Needs Its Backend: OAuth2 Token Security in Single-Page Applications"},"content":{"rendered":"\n

The world of web development has changed a lot in the last decade. We’ve moved from traditional, multi-page websites that build pages on a server, to single-page applications (SPAs)<\/strong>, which have become a popular way to build websites. While old-school sites need to reload the entire page for every user action, causing noticeable delays, SPAs feel more fluid and app-like. They use JavaScript to update content dynamically without reloading the page. This shift has been helped by powerful JavaScript frameworks like React, Angular, and Vue, which give developers great tools to build complex, interactive apps. However, this approach, where most of the work happens in your browser, also creates unique security challenges.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Traditional websites often start with an HTML template. The server then requests the necessary user-specific data and generates the HTML page, incorporating the retrieved data and user-specific information into the template. This is often done using server-side languages like PHP, Python, or Java. In SPAs, however, all the code to update the page runs directly in your browser. The client-side logic, written in JavaScript, will typically call APIs that return the dynamic content. The problem is that these APIs aren’t usually open to everyone; they need some form of authorisation<\/strong>. <\/p>\n\n\n\n

In this article, we’ll focus on the security issues of using the OAuth2 standard in SPAs, as it\u2019s one of the most common ways to authorise APIs today.<\/p>\n\n\n\n

OAuth2 security in single-page applications<\/strong><\/h3>\n\n\n\n

The first problem with OAuth2 security for SPAs is with client (application) authentication<\/strong>. In short, an SPA shouldn’t have any secret keys or passwords stored in its code, because anyone can see them in their browser. This means the OAuth2 client can’t use a secret to prove its identity. Originally, the OAuth2 \u2018implicit grant flow\u2019 was created for this situation, as it skipped this authentication step. However, this method had security weaknesses and was officially removed in OAuth standard version 2.1.<\/p>\n\n\n\n

It’s been replaced by the authorisation grant flow with PKCE<\/strong> (Proof Key for Code Exchange). PKCE is clever because it uses a unique, temporary challenge for each login attempt instead of a fixed, reusable secret. By using this flow, the SPA doesn’t need to store a secret value, but can still prove its identity securely.<\/p>\n\n\n\n

The second problem SPAs face is how to store the access tokens<\/strong> (and optional refresh tokens). These tokens need to be stored somewhere in the browser, like localStorage, sessionStorage or in memory. While each storage type has its pros and cons, they are all at risk from malicious JavaScript. With modern SPAs being so complex, it’s very difficult to completely protect against Cross-Site Scripting (XSS)<\/strong> attacks, making token theft an attractive target for attackers. While there isn’t a universally agreed-upon solution for this, we’ll explain a popular design pattern that improves token security in SPAs.<\/p>\n\n\n\n

The Backend for Frontend pattern<\/strong><\/h3>\n\n\n\n

The Backend for Frontend (BFF)<\/strong> is a design pattern where each frontend application (like an iOS app, Android app, or web app) gets its own dedicated backend. This is different from having one giant backend that serves everything. In terms of token security, the BFF is a small, simple backend that works alongside the SPA.<\/p>\n\n\n\n

Here’s how it works:<\/p>\n\n\n\n