Connexion et génération de JWT

In the previous lesson, we learned about user registration and secure password hashing. Now, it's time to build the login system!

A login system allows authenticated users to access protected resources and personalize their experience within your SaaS application.

When a user tries to log in, they typically provide a username (or email) and a password. Here's the basic flow:

• The client (e.g., your mobile app) sends credentials to the server.
• The server verifies these credentials against its stored user data.
• If valid, the server grants access.

Upon receiving login credentials, your server needs to perform a crucial check:

1. Find the user by their unique identifier (e.g., email or username).
2. Retrieve the stored hashed password for that user.
3. Compare the provided password (after hashing it with the same method) with the stored hashed password.

Never store passwords in plain text! Always hash and salt them, as we discussed in the registration lesson.

Modern APIs are often stateless, meaning the server doesn't remember previous requests from the same client. This makes APIs scalable but poses a challenge for user authentication.

How do we know if a user who just logged in is still authenticated on their next request without sending credentials every time?

JSON Web Tokens (JWTs) are a compact, URL-safe means of representing claims to be transferred between two parties. They are perfect for stateless authentication.

Instead of server-side sessions, the server issues a JWT upon successful login. The client then stores this token and sends it with every subsequent request.

A JWT consists of three parts separated by dots: Header, Payload, and Signature.

The Header typically contains two parts:

• typ (type of token, usually 'JWT')
• alg (signing algorithm, e.g., 'HS256' for HMAC SHA256)

It's a JSON object, Base64Url-encoded.

The Payload contains the 'claims' – statements about an entity (usually the user) and additional data.

Claims can be:

• Registered: Standard fields like sub (subject), exp (expiration time), iat (issued at time).
• Public: Custom claims defined by you, but registered in the IANA JSON Web Token Registry.
• Private: Custom claims agreed upon by the parties using them, like userId or role.

Example Payload:

The Signature is crucial for verifying the token's integrity. It's created by taking the encoded header, the encoded payload, and a secret key, then applying the algorithm specified in the header.

If anyone tries to tamper with the header or payload, the signature verification will fail, making the token invalid. The secret key is known only to the server.

After successfully verifying a user's credentials, your server generates a JWT. This involves:

1. Creating the Header and Payload JSON objects.
2. Base64Url-encoding both.
3. Concatenating them with a dot.
4. Signing the combined string using a secret key and the chosen algorithm to produce the Signature.

The final JWT is EncodedHeader.EncodedPayload.Signature.

While full JWT signing requires a library, we can demonstrate the Base64 encoding part of building a JWT string. This ensures the token is URL-safe.

You've just learned about the three main parts of a JSON Web Token (JWT).

Great job! You've learned how a user login system works and the role of JSON Web Tokens (JWTs) in modern, stateless authentication.

• Login involves verifying credentials against hashed passwords.
• JWTs provide a stateless way to manage user sessions.
• JWTs have three parts: Header, Payload, and Signature.
• The Signature ensures the token's integrity.

Next, we'll explore how to use these JWTs to protect your API routes!