Secure Login Token Management: An Essential Frontend Strategy

Below is a commonly seen code snippet for login and API requests in Single Page Applications (SPA):

async function login(id, pw) {
const res = await fetch('<cross_origin_api_url>/api/auth', {
method: 'POST',
body: encrypt({id, pw}),
mode: 'cors'
});
const token = await res.json();
localStorage.setItem('accessToken', token.accessToken);
}

async function getProtectedResource(id) {
const accessToken = localStorage.getItem('accessToken');
const res = fetch(`<cross_origin_api_url>/api/protected-resource/${id}`, {
headers: {
Authorization: `Bearer ${accessToken}`
},
mode: 'cors'
});
}

The code has the following context:

1. API Agreement with the Backend

• Tokens are included in the Authorization header for authentication.
• Access-Control-Allow-Origin header is set to * to allow all origins, for development convenience.

2. Token Persistence

• The localStorage API is used to store tokens for reuse across user sessions.

Based on the provided code and its context, the following threats are exposed:

Authorization Header → Vulnerable to XSS Attack

Using the Authorization header to send the access token can be vulnerable to XSS attacks. For tokens to be included in the Authorization header, they must be stored in either JavaScript memory or some form of storage. If an attacker successfully executes an XSS attack, they gain access to the page's JavaScript environment. Any globally exposed tokens or functions to retrieve tokens can be accessed and subsequently stolen by the attacker.

LocalStorage → Vulnerable to XSS Attack

In the given code, localStorage is used for token persistence. Since localStorage is accessible globally within the browser, knowing the key is sufficient to retrieve the token. In the case of a successful XSS attack, the token stored in localStorage can be easily stolen by the attacker, making this storage method highly vulnerable.

Access-Control-Allow-Origin: * → Vulnerable to Session Hijacking, CSRF

Browsers implement Cross-Origin Resource Sharing (CORS) policies to prevent sensitive information from being sent across different origins without proper authorization. Allowing Access-Control-Allow-Origin: * in server responses permits requests from any origin, essentially making the server accessible to all sources, even unrelated or malicious ones.

While this permissive CORS configuration does not directly cause CSRF vulnerabilities, it exacerbates the risks. If a CSRF attack occurs, the server's indiscriminate acceptance of requests increases the potential impact, amplifying the damage caused by the attack.

Improving Authentication Methods

To securely manage tokens on the frontend, paradoxically, it is more effective to manage them passively through properly secured cookies rather than actively managing them in the code. The following measures are recommended to enhance token security:

Enforce HTTPS Communication

Although it may seem like a given today, failing to use HTTPS leaves your system vulnerable to Man-in-the-Middle (MitM) attacks, regardless of how robust your code-level security measures are. HTTPS is fundamental and non-negotiable.

Replace Web Storage with Cookies for Persistence

Instead of using the Web Storage API (which is vulnerable to XSS attacks), store sensitive data like tokens in cookies. While cookies themselves are not immune to CSRF or XSS vulnerabilities, the following configurations significantly reduce these risks:

• HTTP Only: Prevents JavaScript from accessing cookies, effectively blocking direct cookie theft via XSS attacks. Cookies in this configuration should always be created server-side.
• SameSite=Strict: Ensures cookies are only sent for requests originating from the same site, substantially mitigating CSRF attacks. If cross-site requests are necessary, use SameSite=Lax at a minimum.
• Secure: Restricts cookie transmission to environments where both the browser and server use HTTPS, offering protection against MitM attacks.
• Granular Domain and Path Settings: Limit the domains and paths that can access each token. This reduces the scope for CSRF attacks and prevents overly broad permissions from being granted due to misconfigurations.

Setting an Appropriate CORS Policy

If your web app is hosted on a domain different from the server’s origin, it is crucial to configure the Access-Control-Allow-Origin header to dynamically allow only specific, authorized domains.

For instance, if your web app hosted at people.abc.com makes a CORS request to defg.com/api, the defg.com/api server should explicitly allow requests originating from people.abc.com:

Access-Control-Allow-Origin: people.abc.com

Additionally, when using cookies for authentication via CORS requests, the server must include additional header settings to send the access token stored in the cookie back to the server.

Access-Control-Allow-Credentials: true

Improved Result

If we implement the solutions as outlined, the improved code would look like this:

async function login(id, pw) {
await fetch('https://<cross_origin_api_url>/api/auth', {
    method: 'POST',
    body: encrypt({id, pw}),
    mode: 'cors'
});
}

async function getProtectedResource(id) {
const res = fetch(`https://<cross_origin_api_url>/api/protected-resource/${id}`, {
mode: 'cors',
credentials: 'include'
});
}

The frontend code has become remarkably simplified. The logic is almost removed, leaving only the settings. However, behind the scenes, many more processes are taking place. Let's break it down to understand how authentication occurs.

What Happens Behind the Scene 1: When login Is Called

The diagram represents the communication flow between the browser and the server when the login function from the example code is invoked.

1. Before sending the request, the browser checks if it is a cross-site request.
2. If the request is cross-site, the browser sends a preflight request to the server (using the OPTIONS method).

• The server evaluates the OPTIONS method request to determine whether the domain is allowed and responds with headers permitting cross-site requests, such as Access-Control-Allow-Origin and Access-Control-Allow-Credentials.

3. The browser reviews the preflight response to ensure the server's headers are appropriate. If the headers are valid, the browser proceeds with the original request.
4. The server processes the authentication request and sets a cookie with security attributes such as HttpOnly, Secure, and SameSite=Lax.
5. The browser securely stores the cookie for subsequent requests.

What Happens Behind the Scene 2: When getProtectedResource is Called

1. Browser - The browser sends a CORS Preflight request to the resource server. This step verifies how the server has configured its CORS headers.
2. Server - Upon receiving the CORS Preflight request for the resource, the server determines whether to include the Access-Control-Allow-Origin header and decides if the request is allowed.
3. If the server correctly sets the CORS headers, the browser proceeds with the actual request. If the credentials field in the request is set to include, the browser verifies whether Access-Control-Allow-Credentials: true is present and includes the cookie in the request headers.
4. Server - The server extracts the token from the included cookie and performs internal authentication. If the user is not logged in or there is a security misconfiguration on the client side, the cookie will be absent, and the server denies access to the resource.

As a result, the system is significantly more secure, offering robust protection against XSS and CSRF attacks.

Let’s Take It a Step Further

Our frontend team significantly improved security and simplified the authentication logic by transitioning from Web Storage-based token management to a cookie-based approach. However, in the realm of security, there is no such thing as a completely foolproof method. Thus, it’s essential to implement additional configurations to minimize potential damage, even if tokens are compromised.

Token Rotation

Token rotation involves shortening the validity period of tokens and frequently refreshing them.

Access tokens with long validity periods pose a significant risk if compromised, as attackers can leverage them for extended periods, potentially causing greater harm. By assigning a short lifecycle to access tokens, you can ensure that even if a token is stolen, its usability expires quickly, limiting the damage.

Refresh Tokens

Short-lived access tokens may inconvenience users by prompting frequent logins. To mitigate this, refresh tokens can be introduced, enabling new access tokens to be issued without requiring users to log in repeatedly. This approach maintains a short lifespan for access tokens while allowing seamless renewal through valid refresh tokens, effectively supporting a robust token rotation strategy.

Secure Frontend Token Authentication Strategies for Safe Web Services

Implementing a secure frontend token authentication mechanism while adhering to basic web security principles is crucial. By reducing complexity and handling critical security processes server-side, you can effectively minimize the attack surface for hackers. Token management on the frontend can be strengthened through cookie-based passive security measures, leveraging browser security policies to handle authentication processes safely.

Additionally, implementing token rotation strategies, such as setting shorter token lifespans and periodic renewals, enhances security and improves user experience by mitigating the risks associated with token theft. With these approaches, you can adopt the secure frontend token authentication framework proposed by QueryPie to deliver safer web services.

References

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
• https://www.okta.com/identity-101/what-is-token-based-authentication/
• https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch