Spring Security 6 & JWT Authentication · Aula

Implementação de tokens de atualização

Desenvolva uma estratégia para emitir e gerenciar tokens de atualização, estendendo com segurança as sessões dos usuários sem exigir autenticação frequente.

Implementação de tokens de atualização é uma aula grátis de Spring Security 6 & JWT Authentication no CoddyKit. Esta é a aula 1 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Spring Security 6 & JWT Authentication, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Spring Security 6 & JWT Authentication inclui 4 aulas no total.

Partes desta aula ainda não foram traduzidas e aparecem em 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.

Perguntas Frequentes

A aula “Implementação de tokens de atualização” é grátis?

Sim — o texto completo de “Implementação de tokens de atualização” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Spring Security 6 & JWT Authentication, atualize para CoddyKit PRO. O curso de Spring Security 6 & JWT Authentication inclui 4 aulas no total.

O que vou aprender em “Implementação de tokens de atualização”?

Desenvolva uma estratégia para emitir e gerenciar tokens de atualização, estendendo com segurança as sessões dos usuários sem exigir autenticação frequente. Você pratica Spring Security 6 & JWT Authentication com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar Spring Security 6 & JWT Authentication?

Nenhuma experiência prévia é necessária. Spring Security 6 & JWT Authentication no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 1 de 4.

Quanto tempo leva a aula “Implementação de tokens de atualização”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de Spring Security 6 & JWT Authentication?

Sim. Cada aula de Spring Security 6 & JWT Authentication inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

Implementação de tokens de atualização
Estratégias de revogação de tokens JWT
Práticas seguras de armazenamento de tokens
Rotação de chaves de assinatura e gerenciamento de chaves

← Voltar para Spring Security 6 & JWT Authentication