实现刷新令牌
制定签发和管理刷新令牌的策略，在无需频繁重新身份验证的情况下安全延长用户会话。
实现刷新令牌 是 CoddyKit 上的免费 Spring Security 6 & JWT Authentication 课时。 这是第 1 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 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.
常见问题解答
「实现刷新令牌」课时是免费的吗？
是的 — 「实现刷新令牌」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Spring Security 6 & JWT Authentication 课程的其余内容，请升级到 CoddyKit PRO。 Spring Security 6 & JWT Authentication 课程共包含 4 节课。
「实现刷新令牌」这节课中我会学到什么？
制定签发和管理刷新令牌的策略，在无需频繁重新身份验证的情况下安全延长用户会话。 你通过在浏览器中直接运行的动手代码来练习 Spring Security 6 & JWT Authentication，全天候 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 反馈 — 无需本地设置。