Implementacja tokenów odświeżania
Opracuj strategię wydawania i zarządzania tokenami odświeżania, aby bezpiecznie przedłużać sesje użytkowników bez częstego ponownego uwierzytelniania.
Implementacja tokenów odświeżania to bezpłatna lekcja Spring Security 6 & JWT Authentication na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Spring Security 6 & JWT Authentication, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Spring Security 6 & JWT Authentication zawiera 4 lekcji w sumie.
Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.
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.
Często zadawane pytania
Czy lekcja „Implementacja tokenów odświeżania” jest bezpłatna?
Tak — pełny tekst „Implementacja tokenów odświeżania” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Spring Security 6 & JWT Authentication, przejdź na CoddyKit PRO. Kurs Spring Security 6 & JWT Authentication zawiera 4 lekcji w sumie.
Co nauczysz się w „Implementacja tokenów odświeżania”?
Opracuj strategię wydawania i zarządzania tokenami odświeżania, aby bezpiecznie przedłużać sesje użytkowników bez częstego ponownego uwierzytelniania. Ćwiczysz Spring Security 6 & JWT Authentication z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć Spring Security 6 & JWT Authentication?
Nie wymagamy żadnego doświadczenia. Spring Security 6 & JWT Authentication w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.
Ile czasu zajmuje lekcja „Implementacja tokenów odświeżania”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji Spring Security 6 & JWT Authentication?
Tak. Każda lekcja Spring Security 6 & JWT Authentication zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Implementacja tokenów odświeżania
- Strategie unieważniania tokenów JWT
- Bezpieczne przechowywanie tokenów
- Rotacja kluczy podpisujących i zarządzanie kluczami