การออกแบบลำดับการยืนยันตัวตนด้วย JWT

Welcome! In this lesson, we'll design the complete journey of a user authenticating with JWTs.

Understanding the 'flow' is crucial. It describes the sequence of steps from when a user logs in until they access protected resources.

JWTs offer a powerful, stateless way to handle user authentication and authorization.

Traditionally, web apps use stateful sessions. The server remembers who you are via a session ID.

Stateless authentication, like with JWTs, means the server doesn't store session data. Each request contains all necessary info (the JWT itself) to verify the user.

This makes scaling easier, as any server can process any request without needing shared session storage.

The authentication flow begins when a user tries to log in. They typically provide their username and password.

This information is usually sent to a specific endpoint on your server, often via an HTTP POST request to something like /api/auth/login.

It's vital to transmit these credentials securely, typically over HTTPS.

Upon receiving the login request, the server's job is to verify the provided credentials.

Spring Security uses components like the AuthenticationManager and UserDetailsService to check if the username exists and if the password matches.

If the credentials are valid, the user is successfully authenticated.

Once the user's identity is verified, the server generates a JSON Web Token (JWT).

This token contains information about the user (called 'claims') and is digitally signed by the server.

The signature ensures that the token hasn't been tampered with and comes from a trusted source.

Here's a simplified, conceptual example of how a server might 'create' a token. Real JWT libraries do much more, including signing.

This snippet just illustrates taking user data and forming a unique string.

After generating the JWT, the server sends it back to the client.

Typically, the JWT is included in the response body of the login request, often as a JSON object.

The client then extracts this token from the response.

Once the client receives the JWT, it needs to store it for future requests.

• Local Storage: Easy to use, persistent across browser sessions.
• Session Storage: Similar to local storage, but cleared when the browser tab closes.
• HTTP-only Cookies: More secure against XSS, but can be susceptible to CSRF.

The choice depends on your application's security requirements and architecture.

For every subsequent request to a protected resource, the client must include the stored JWT.

The standard way to do this is by adding an Authorization header to the HTTP request.

The header value typically starts with Bearer, followed by a space and then the JWT itself: Authorization: Bearer [your_jwt_here].

When a request with a JWT arrives at the server, Spring Security intercepts it.

The server then performs several checks:

• Is the token format valid?
• Is the signature valid (using the secret key)?
• Has the token expired?
• Are the claims (e.g., user roles) sufficient for the requested resource?

Only if all checks pass is access granted.

Let's test your understanding of the JWT authentication flow.

After a user successfully logs in and the server authenticates their credentials, what are the crucial next steps in a typical JWT authentication flow?

You've successfully designed the JWT authentication flow!

We covered the journey from a user's login request, through server-side authentication and JWT generation, to the client receiving, storing, and using the token for subsequent protected resource access.

This stateless approach enhances scalability and flexibility. Next, we'll dive into implementing a custom JWT filter!