Issue, refresh và revoke JWT — vòng đời token trong production

TL;DR: Điểm đăng nhập (/login) sử dụng NimbusJwtEncoder để cấp phát cặp token: Access Token ngắn hạn (15-60 phút) dùng gọi API và Refresh Token dài hạn (7-30 ngày) dùng để xin cấp lại token mới. Khi Access Token hết hạn, client gửi Refresh Token lên endpoint /refresh để áp dụng cơ chế xoay vòng (Refresh Token Rotation): hủy token cũ và cấp phát cặp token hoàn toàn mới. Để giải quyết bài toán thu hồi token trong kiến trúc stateless, ba giải pháp phổ biến gồm: thời hạn sống ngắn, danh sách đen Redis (Denylist) hoặc lưu trữ trạng thái Refresh Token trong cơ sở dữ liệu.

Tại sao hệ thống cần mô hình Access Token ngắn kết hợp Refresh Token dài?

Tính chất phi trạng thái (stateless) của JWT giúp hệ thống mở rộng quy mô dễ dàng nhưng cũng tạo ra rào cản lớn: khi token đã phát hành, máy chủ không thể thu hồi nó trước thời điểm hết hạn (exp).

Mô hình kết hợp giải quyết bài toán đánh đổi này:

Nếu chỉ dùng một Access Token duy nhất có hạn 24 giờ, khi người dùng đổi mật khẩu hoặc bị lộ máy tính, kẻ tấn công có thể truy cập hệ thống suốt một ngày mà không có cách nào chặn đứng tức thì.

Làm thế nào để cấu hình JwtEncoder phát hành token chuẩn xác?

Spring Security cung cấp interface JwtEncoder để tạo và ký số cho token. Triển khai chuẩn mực bằng NimbusJwtEncoder:

@Configuration
public class JwtEncoderConfig {

    @Value("${app.jwt.secret}")
    private String secret; // Loaded from environment variable

    @Bean
    public JwtEncoder jwtEncoder() {
        SecretKey key = new SecretKeySpec(
            secret.getBytes(StandardCharsets.UTF_8), "HmacSHA256"
        );
        OctetSequenceKey jwk = new OctetSequenceKey.Builder(key).build();
        JWKSource<SecurityContext> jwkSource = new ImmutableJWKSet<>(new JWKSet(jwk));
        return new NimbusJwtEncoder(jwkSource);
    }
}

Cơ chế JwtIssuer tạo Access Token và Refresh Token ra sao?

Dịch vụ phát hành token chịu trách nhiệm đóng gói các claims:

@Service
@RequiredArgsConstructor
public class JwtIssuer {

    private final JwtEncoder encoder;

    public String issueAccessToken(UserDetails user) {
        Instant now = Instant.now();
        List<String> roles = user.getAuthorities().stream()
            .map(GrantedAuthority::getAuthority)
            .map(auth -> auth.replaceFirst("^ROLE_", ""))
            .toList();

        JwtClaimsSet claims = JwtClaimsSet.builder()
            .issuer("olhub.org")
            .subject(user.getUsername())
            .audience(List.of("olhub-api"))
            .issuedAt(now)
            .expiresAt(now.plus(Duration.ofMinutes(15))) // Short-lived: 15 mins
            .id(UUID.randomUUID().toString())            // jti for revocation
            .claim("roles", roles)
            .build();

        return encoder.encode(JwtEncoderParameters.from(claims)).getTokenValue();
    }

    public String issueRefreshToken(UserDetails user) {
        Instant now = Instant.now();
        JwtClaimsSet claims = JwtClaimsSet.builder()
            .issuer("olhub.org")
            .subject(user.getUsername())
            .issuedAt(now)
            .expiresAt(now.plus(Duration.ofDays(30)))     // Long-lived: 30 days
            .id(UUID.randomUUID().toString())
            .claim("type", "refresh")                    // Guard claim
            .build();

        return encoder.encode(JwtEncoderParameters.from(claims)).getTokenValue();
    }
}

Claim "type": "refresh" đóng vai trò hàng rào bảo vệ, ngăn client dùng nhầm Access Token để gọi endpoint làm mới token.

Endpoint đăng nhập (/login) xử lý việc cấp phát token như thế nào?

Controller tiếp nhận yêu cầu, ủy quyền cho AuthenticationManager kiểm tra mật khẩu rồi phát hành cặp token:

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

    private final AuthenticationManager authManager;
    private final JwtIssuer jwtIssuer;
    private final RefreshTokenStore tokenStore;

    @PostMapping("/login")
    public TokenResponse login(@Valid @RequestBody LoginRequest req) {
        Authentication auth = authManager.authenticate(
            new UsernamePasswordAuthenticationToken(req.email(), req.password())
        );
        UserDetails user = (UserDetails) auth.getPrincipal();

        String access = jwtIssuer.issueAccessToken(user);
        String refresh = jwtIssuer.issueRefreshToken(user);

        tokenStore.save(user.getUsername(), refresh);

        return new TokenResponse(access, refresh, "Bearer", 900L);
    }
}

Cơ chế xoay vòng Refresh Token (Rotation) hoạt động ra sao?

Mỗi lần client yêu cầu cấp lại Access Token, máy chủ hủy ngay Refresh Token cũ và cấp một Refresh Token mới (Refresh Token Rotation):

@PostMapping("/refresh")
public TokenResponse refresh(@Valid @RequestBody RefreshRequest req) {
    Jwt jwt = refreshTokenDecoder.decode(req.refreshToken());

    if (!"refresh".equals(jwt.getClaim("type"))) {
        throw new InvalidBearerTokenException("Invalid token type");
    }

    String jti = jwt.getId();
    if (!tokenStore.isValid(jti)) {
        // Reuse detection: If revoked token is presented, compromise detected
        tokenStore.revokeAllForUser(jwt.getSubject());
        throw new InvalidBearerTokenException("Token compromised");
    }

    tokenStore.revoke(jti); // Invalidate used token

    UserDetails user = userDetailsService.loadUserByUsername(jwt.getSubject());
    String newAccess = jwtIssuer.issueAccessToken(user);
    String newRefresh = jwtIssuer.issueRefreshToken(user);

    tokenStore.save(user.getUsername(), newRefresh);

    return new TokenResponse(newAccess, newRefresh, "Bearer", 900L);
}

Cơ chế này tạo ra tín hiệu cảnh báo phát hiện xâm nhập: nếu một Refresh Token đã bị thu hồi đột ngột được gửi lên máy chủ lần thứ hai, hệ thống biết ngay rằng token đã bị rò rỉ cho bên thứ ba và tự động hủy bỏ toàn bộ phiên của người dùng đó.

Ba chiến lược thu hồi (Revocation) token trong kiến trúc Stateless là gì?

1. Thời hạn sống ngắn (Short Expiry)

Giải pháp đơn giản nhất không đòi hỏi thêm cơ sở hạ tầng. Access Token chỉ sống từ 5 đến 15 phút. Khi người dùng đăng xuất, hệ thống chỉ hủy Refresh Token. Cửa sổ rủi ro tối đa chỉ kéo dài bằng thời gian còn lại của Access Token.

2. Danh sách đen trong Redis (Redis Denylist)

Khi cần thu hồi Access Token ngay lập tức (admin khóa tài khoản, đổi mật khẩu), ghi mã jti của token vào Redis với thời gian TTL bằng đúng thời hạn còn lại của token. Bộ lọc OncePerRequestFilter kiểm tra Redis trên mỗi request.

3. Lưu trữ Refresh Token trong Cơ sở dữ liệu (Khuyến nghị Production)

Lưu trữ thông tin Refresh Token trong bảng cơ sở dữ liệu (refresh_tokens). Cung cấp khả năng thu hồi theo từng thiết bị hoặc xóa toàn bộ phiên đăng nhập của người dùng (revokeAllForUser).

Tại sao việc thu hồi token trong hệ thống Stateless lại phức tạp?

Bản chất của JWT là token tự chứa (self-contained) và token người cầm (bearer token):

Máy chủ chỉ kiểm tra chữ ký có khớp không và thời hạn đã qua chưa, hoàn toàn không tra cứu trạng thái session trong database. Việc kết hợp Access Token ngắn và lưu Refresh Token trong DB là sự cân bằng tối ưu giữa hiệu năng mở rộng và khả năng kiểm soát an ninh.

Những cạm bẫy bảo mật kinh điển khi quản lý vòng đời JWT là gì?

• Hardcode JWT Secret: Tuyệt đối không lưu khóa bí mật trong mã nguồn git; nạp qua biến môi trường hoặc Vault.
• Không thiết lập claim exp: Biến token thành vĩnh cửu, không bao giờ hết hạn.
• Để lộ dữ liệu nhạy cảm trong Payload: Bất kỳ ai cầm token cũng giải mã được các trường claims.
• Bỏ qua kiểm tra loại token tại /refresh: Cho phép kẻ xấu dùng chính Access Token để xin cấp phát token mới.

Những điểm then chốt cần ghi nhớ là gì?

• Sử dụng mô hình Access Token ngắn (15 phút) kết hợp Refresh Token dài hạn (30 ngày).
• Luôn gắn claim jti duy nhất cho mỗi token để hỗ trợ truy vết và đưa vào danh sách đen.
• Áp dụng kỹ thuật Refresh Token Rotation: đổi token và phát hiện xâm nhập khi token cũ bị tái sử dụng.
• Lưu trữ Refresh Token trong cơ sở dữ liệu để hỗ trợ tính năng đăng xuất toàn bộ thiết bị.

Bạn đã nắm vững vòng đời phát hành và xoay vòng JWT chưa?

Bài tiếp theo: Tổng kết module