Spring Security 6 & JWT Authentication · Leçon

Mise en œuvre des jetons d’actualisation

Élaborez une stratégie d’émission et de gestion des jetons d’actualisation afin de prolonger les sessions des utilisateurs en toute sécurité, sans réauthentification fréquente.

Mise en œuvre des jetons d’actualisation est une leçon Spring Security 6 & JWT Authentication gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Spring Security 6 & JWT Authentication, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Spring Security 6 & JWT Authentication comprend 4 leçons au total.

Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.

Why Short-Lived Access Tokens?

In modern security, Access Tokens (like JWTs) are typically designed to be short-lived. This means they expire quickly, often within minutes or a few hours.

Why? If an access token is stolen, its short lifespan limits the time an attacker can use it to impersonate a user. This reduces the window of vulnerability.

The User Experience Challenge

While short-lived access tokens are great for security, they can create a poor user experience. Imagine needing to log in every 15 minutes because your access token expired!

Users expect to stay logged in for extended periods without constant re-authentication. This is where Refresh Tokens come to the rescue.

Introducing Refresh Tokens

A Refresh Token is a special, long-lived token issued alongside the short-lived access token during a user's initial login.

It's not used to access resources directly.
Its sole purpose is to obtain a new, valid access token once the current one expires.
They typically have a much longer expiry (days, weeks, or even months).

The Refresh Token Flow

Here's how refresh tokens maintain user sessions securely:

Login: User authenticates, receives both an Access Token and a Refresh Token.
Access: User uses the access token for API requests.
Expiration: When the access token expires, API requests fail.
Refresh: The client sends the refresh token to a special endpoint to get a new access token.
Continue: If the refresh token is valid, a new access token is issued, and the user continues without re-login.

Generating Refresh Tokens

Refresh tokens are often also JWTs, but with different claims and a much longer expiration time. They might include a 'type': 'refresh' claim to distinguish them from access tokens.

Here's a simplified example of how a JWT (acting as a refresh token) could be generated with a long expiry:

import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;
import io.jsonwebtoken.security.Keys;
import java.security.Key;
import java.util.Date;
import java.util.concurrent.TimeUnit;

public class RefreshTokenGenerator {

  private static final Key SECRET_KEY = Keys.secretKeyFor(SignatureAlgorithm.HS256);

  public static String generateRefreshToken(String username) {
    long nowMillis = System.currentTimeMillis();
    Date now = new Date(nowMillis);
    // Refresh token valid for 7 days
    long expiryMillis = nowMillis + TimeUnit.DAYS.toMillis(7);
    Date expiry = new Date(expiryMillis);

    return Jwts.builder()
        .setSubject(username)
        .claim("token_type", "refresh") // Custom claim
        .setIssuedAt(now)
        .setExpiration(expiry)
        .signWith(SECRET_KEY)
        .compact();
  }

  public static void main(String[] args) {
    String user = "coddykit_user";
    String refreshToken = generateRefreshToken(user);
    System.out.println("Generated Refresh Token for " + user + ":");
    System.out.println(refreshToken);
  }
}

Secure Client-Side Storage

Where should the client store the refresh token? This is critical for security:

HTTP-only Cookies: For web applications, this is the most secure option. The browser sends them automatically, and JavaScript cannot access them, preventing XSS attacks.
Secure Storage: For mobile apps, platform-specific secure storage (e.g., iOS Keychain, Android Keystore) should be used.

Never store refresh tokens in Local Storage! It's vulnerable to XSS.

Server-Side Management

For enhanced security and control, refresh tokens are often managed on the server-side as well:

Database Storage: Store refresh tokens (or their hashes) in a database, linked to the user.
Revocation: This allows the server to invalidate a refresh token immediately (e.g., if a user logs out, changes password, or a token is suspected to be compromised).
One-Time Use: Some implementations make refresh tokens single-use, issuing a new one with each refresh request.

The Refresh Endpoint

Your Spring Boot application needs a dedicated API endpoint (e.g., /api/auth/refresh) that clients can call to exchange a valid refresh token for a new access token.

This endpoint should:

Receive the refresh token from the client.
Validate the refresh token's signature, claims, and expiry.
Verify it against server-side storage (if applicable).
If valid, generate and return a new access token (and potentially a new refresh token).

Refresh Endpoint Logic (Snippet)

Here's a conceptual snippet of a Spring controller method that handles a refresh request. Note that `isRunnable` is false as this is part of a larger Spring application context.

@RestController
@RequestMapping("/api/auth")
public class AuthController {

    @Autowired
    private JwtService jwtService;

    @Autowired
    private RefreshTokenService refreshTokenService;

    @PostMapping("/refresh")
    public ResponseEntity<TokenResponse> refreshAccessToken(@RequestBody RefreshRequest refreshRequest) {
        String oldRefreshToken = refreshRequest.getRefreshToken();
        
        // 1. Validate the old refresh token
        if (!jwtService.validateToken(oldRefreshToken) || !refreshTokenService.isValidRefreshToken(oldRefreshToken)) {
            return ResponseEntity.status(HttpStatus.UNAUTHORIZED).build();
        }

        String username = jwtService.extractUsername(oldRefreshToken);
        // 2. Generate new access token
        String newAccessToken = jwtService.generateAccessToken(username);
        // 3. (Optional) Generate a new refresh token and invalidate the old one
        String newRefreshToken = refreshTokenService.rotateRefreshToken(oldRefreshToken, username);

        return ResponseEntity.ok(new TokenResponse(newAccessToken, newRefreshToken));
    }
}

Refresh Token Check

Which of the following are secure practices for managing refresh tokens?

Recap: Secure Sessions with Refresh Tokens

You've learned how Refresh Tokens are crucial for balancing strong security with a great user experience in applications using short-lived access tokens.

They allow users to remain authenticated for longer periods.
Secure storage (HTTP-only cookies, secure mobile storage) is vital.
Server-side management enables revocation and token rotation for enhanced security.

This mechanism is fundamental for robust, modern authentication systems.

Questions Fréquemment Posées

La leçon « Mise en œuvre des jetons d’actualisation » est-elle gratuite ?

Oui — le texte complet de « Mise en œuvre des jetons d’actualisation » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Spring Security 6 & JWT Authentication, passe à CoddyKit PRO. Le cours Spring Security 6 & JWT Authentication comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Mise en œuvre des jetons d’actualisation » ?

Élaborez une stratégie d’émission et de gestion des jetons d’actualisation afin de prolonger les sessions des utilisateurs en toute sécurité, sans réauthentification fréquente. Tu pratiques Spring Security 6 & JWT Authentication avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Spring Security 6 & JWT Authentication ?

Aucune expérience préalable n'est requise. Spring Security 6 & JWT Authentication sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.

Combien de temps prend la leçon « Mise en œuvre des jetons d’actualisation » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Spring Security 6 & JWT Authentication ?

Oui. Chaque leçon Spring Security 6 & JWT Authentication inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

Mise en œuvre des jetons d’actualisation
Stratégies de révocation des jetons JWT
Bonnes pratiques de stockage sécurisé des jetons
Rotation des clés de signature et gestion des clés

← Retour à Spring Security 6 & JWT Authentication