Spring Security 6 & JWT Authentication · レッスン

リフレッシュトークンの実装

頻繁な再認証なしにユーザーセッションを安全に延長できるよう、リフレッシュトークンを発行・管理する戦略を開発します。

「リフレッシュトークンの実装」はCoddyKit上の無料Spring Security 6 & JWT Authenticationレッスンです。これはレッスン1/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応の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時間対応のAIチューター）、Spring Security 6 & JWT Authenticationコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Spring Security 6 & JWT Authenticationコースには全4レッスンが含まれています。

「リフレッシュトークンの実装」で何を学びますか？

頻繁な再認証なしにユーザーセッションを安全に延長できるよう、リフレッシュトークンを発行・管理する戦略を開発します。ブラウザで直接実行するハンズオンコードでSpring Security 6 & JWT Authenticationを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Spring Security 6 & JWT Authenticationを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのSpring Security 6 & JWT Authenticationは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン1/4です。

「リフレッシュトークンの実装」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このSpring Security 6 & JWT Authenticationレッスンでコードを書いて実行できますか？

はい。すべてのSpring Security 6 & JWT Authenticationレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Spring Security 6 & JWT Authenticationに戻る