Spring Security 6 & JWT Authentication · Lección

Implementación de tokens de actualización

Desarrolle una estrategia para emitir y gestionar tokens de actualización con el fin de ampliar las sesiones de usuario de forma segura sin reautenticaciones frecuentes.

Implementación de tokens de actualización es una lección gratuita de Spring Security 6 & JWT Authentication en CoddyKit. Esta es la lección 1 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Spring Security 6 & JWT Authentication, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Spring Security 6 & JWT Authentication incluye 4 lecciones en total.

Partes de esta lección aún no han sido traducidas y se muestran en inglés.

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.

Preguntas frecuentes

¿La lección «Implementación de tokens de actualización» es gratis?

Sí — el texto completo de «Implementación de tokens de actualización» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Spring Security 6 & JWT Authentication, actualiza a CoddyKit PRO. El curso de Spring Security 6 & JWT Authentication incluye 4 lecciones en total.

¿Qué aprenderé en «Implementación de tokens de actualización»?

Desarrolle una estrategia para emitir y gestionar tokens de actualización con el fin de ampliar las sesiones de usuario de forma segura sin reautenticaciones frecuentes. Practicas Spring Security 6 & JWT Authentication con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar Spring Security 6 & JWT Authentication?

No se requiere experiencia previa. Spring Security 6 & JWT Authentication en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 1 de 4.

¿Cuánto tiempo toma la lección «Implementación de tokens de actualización»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de Spring Security 6 & JWT Authentication?

Sí. Cada lección de Spring Security 6 & JWT Authentication incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

Implementación de tokens de actualización
Estrategias de revocación de tokens JWT
Prácticas seguras para almacenar tokens
Rotación de claves de firma y gestión de claves

← Volver a Spring Security 6 & JWT Authentication