Spring Security 6 & JWT Authentication · 강의

리프레시 토큰 구현

잦은 재인증 없이 사용자 세션을 안전하게 연장할 수 있도록 리프레시 토큰을 발급하고 관리하는 전략을 개발합니다.

리프레시 토큰 구현은(는) CoddyKit의 무료 Spring Security 6 & JWT Authentication 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Spring Security 6 & JWT Authentication 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Spring Security 6 & JWT Authentication 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

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.

자주 묻는 질문

“리프레시 토큰 구현” 강의는 무료인가요?

네 — “리프레시 토큰 구현” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Spring Security 6 & JWT Authentication 강의 전체를 잠금 해제할 수 있습니다. Spring Security 6 & JWT Authentication 강의에는 총 4개의 강의가 포함되어 있습니다.

“리프레시 토큰 구현”에서 뭘 배우나요?

잦은 재인증 없이 사용자 세션을 안전하게 연장할 수 있도록 리프레시 토큰을 발급하고 관리하는 전략을 개발합니다. 브라우저에서 직접 실행하는 실습 코드로 Spring Security 6 & JWT Authentication을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Spring Security 6 & JWT Authentication을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Spring Security 6 & JWT Authentication은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.

“리프레시 토큰 구현” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Spring Security 6 & JWT Authentication 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Spring Security 6 & JWT Authentication 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Spring Security 6 & JWT Authentication(으)로 돌아가기