JWT Authentication in SPAs

1. From Stateful Sessions to Stateless Tokens

As a Laravel developer, you're likely familiar with traditional server-side sessions. In that model, the server creates a session for a user upon login, stores that session data (e.g., in a file or a Redis cache), and gives the browser a cookie with a session ID. On every subsequent request, the browser sends the cookie, the server looks up the session data using the ID, and verifies the user.

This works well, but can become a bottleneck in modern, large-scale applications. If you have multiple backend servers (a "distributed system"), you need to make sure all servers can access the session data, which adds complexity and cost.

This is the problem that JSON Web Tokens (JWT) were designed to solve. They enable a stateless authentication model. The server doesn't need to store any information about the user's session. Instead, all the necessary information is contained within a "token" that the client holds.

2. What is a JSON Web Token (JWT)?

A JWT is a compact, self-contained JSON object that is used to securely transmit information between parties. The key is that it's "signed" by the server, so you can trust that the information within it is authentic and hasn't been tampered with.

Let's start with a short animated video that gives an excellent high-level overview of JWTs.

As the video explained, a JWT consists of three parts separated by dots: xxxxx.yyyyy.zzzzz.

Let's dig a little deeper into that structure using the official documentation from jwt.io.

The most crucial part is the signature. It's created by the server using the header, the payload, and a secret key that only the server knows. When the client sends the token back to the server, the server can regenerate the signature with its secret key. If the regenerated signature matches the one on the token, the server knows two things:

1. The token was issued by this server (authenticity).
2. The payload has not been changed since it was issued (integrity).

3. The Authentication Flow in an SPA

Now let's map this theory to the application we're building. How does a React SPA use JWTs to talk to a Laravel API?

The flow is as follows:

1. Login: The user enters their email and password into a form in our React app.
2. Token Request: The React app sends these credentials in a POST request to a /login endpoint on the Laravel backend.
3. Validation & Token Creation: The Laravel server validates the credentials against the database. If they are correct, it creates a JWT. The payload contains user information (like user ID, role, etc.), and the token is signed with a secret key stored securely on the server.
4. Token Response: The server sends the signed JWT back to the React app in the response body.
5. Token Storage: The React app receives the token and stores it somewhere in the browser (we'll discuss where and the security implications shortly).
6. Authenticated Requests: For any subsequent request to a protected API endpoint (e.g., to get user profile data), the React app includes the JWT in the Authorization header. The standard format is Authorization: Bearer <token>.
7. Server Verification: The Laravel server receives the request, extracts the token from the header, and verifies its signature. If the signature is valid and the token hasn't expired, the server trusts the claims in the payload and processes the request.

This diagram provides a great visual of this entire process.

To reinforce this, let's read the section from jwt.io that describes this exact flow.

4. Security in SPAs: Where to Store the Token?

This all sounds great, but there's a critical question: where does the React app store the token? The most common and simplest place is the browser's localStorage.

However, this approach has a significant security vulnerability: Cross-Site Scripting (XSS). If an attacker can inject a malicious script onto your page (perhaps through a compromised third-party library), that script can read anything in localStorage, steal the JWT, and use it to impersonate your user.

There are more secure alternatives. Let's watch a video that explains the risk of localStorage and introduces a more robust architectural pattern called Backend-for-Frontend (BFF).

To summarize the trade-offs:

For our project, we will start by using the localStorage method. It is crucial to learn this pattern as it's widely used, and it allows us to focus on the React-specific logic of handling authentication state. Later, when we integrate deeply with Laravel, we'll be perfectly positioned to implement the more secure BFF pattern, which aligns with Laravel Sanctum.

Conclusion

In this lesson, you've learned the fundamental theory behind modern web authentication. This knowledge is not just abstract; it's the blueprint for the features we are about to build.

Key Takeaways:

• JWTs provide a stateless way to handle authentication, which is ideal for modern SPAs and distributed systems.
• A JWT consists of a Header, a Payload (containing claims like user ID and expiration), and a Signature (which guarantees authenticity and integrity).
• The standard flow involves the client logging in to get a token, storing it, and sending it with every API request in the Authorization: Bearer header.
• Storing JWTs in browser localStorage is a simple but common pattern that is vulnerable to XSS attacks. More secure patterns like BFF exist and are important to be aware of.

Preview of the Next Lesson:

Now that we understand the theory, it's time to get our hands dirty. In the next lesson, you will begin the practical work by building the UI for our registration form using React, setting the stage to capture user data and send it to a backend.