Czarne i białe listy tokenów JWT
Poznaj zaawansowane techniki unieważniania tokenów, w tym zarządzanie czarnymi lub białymi listami tokenów.
Czarne i białe listy tokenów JWT to bezpłatna lekcja Spring Security 6 & JWT Authentication na CoddyKit. To lekcja 2 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 Revoke JWTs?
JSON Web Tokens (JWTs) are powerful for authentication, but sometimes you need to invalidate them before their natural expiry. This process is called token revocation.
- Compromised Token: If a token is stolen.
- User Logout: To immediately end a user's session.
- Password Change: To invalidate all old tokens.
- Role Changes: To force re-authentication with new permissions.
The Stateless Challenge
JWTs are inherently stateless. Once issued, they contain all necessary information for validation and don't require the server to store session data.
This statelessness is a strength, but it makes direct server-side revocation tricky. The server typically doesn't hold a list of active tokens to simply 'turn off'.
Blacklisting Explained
Blacklisting is a common strategy to revoke JWTs. When a token needs to be invalidated, its unique identifier (often the JTI claim) is added to a 'blacklist' — a list of forbidden tokens.
- Any token whose JTI is on this list is rejected, even if it's cryptographically valid and not expired.
- This allows you to 'undo' a token's validity.
Implementing a Blacklist
The blacklist needs to be stored in a highly available, fast-access data store. Speed is crucial because every incoming request might need to check this list.
- Redis: An excellent choice due to its in-memory nature and support for time-to-live (TTL) on entries, which can match token expiry.
- Database: A simple table can work, but might be slower for high-volume checks.
- Each entry typically stores the JWT's JTI and its original expiry time.
Simple Blacklist Service
Here's a basic interface for a service that manages a token blacklist. In a real application, this would interact with a database or a caching system like Redis.
public interface TokenBlacklistService {
void blacklistToken(String jti, long expirySeconds);
boolean isBlacklisted(String jti);
}JWT Filter with Blacklist Check
When a request arrives, a security filter would first validate the JWT's signature and expiry. Then, it would check if the token's JTI is present on the blacklist before granting access.
Try running this example:
import java.util.HashSet;
import java.util.Set;
// A simplified in-memory blacklist for demonstration
class MockTokenBlacklistService {
private Set<String> blacklistedJtis = new HashSet<>();
public void blacklistToken(String jti, long expirySeconds) {
System.out.println("Action: Blacklisting JTI " + jti);
blacklistedJtis.add(jti);
// In a real app, 'expirySeconds' would set a TTL on the blacklist entry
}
public boolean isBlacklisted(String jti) {
boolean result = blacklistedJtis.contains(jti);
System.out.println("Check: Is JTI " + jti + " blacklisted? " + result);
return result;
}
}
public class Main {
public static void main(String[] args) {
MockTokenBlacklistService blacklist = new MockTokenBlacklistService();
String userTokenJti = "user-abc-123";
String adminTokenJti = "admin-def-456";
// Simulate an admin token being revoked after a security event
blacklist.blacklistToken(adminTokenJti, 3600); // Token expires in 1 hour
// Check access for different tokens
System.out.println("\n--- Access Checks ---");
System.out.println("User token access: " + (blacklist.isBlacklisted(userTokenJti) ? "DENIED" : "GRANTED"));
System.out.println("Admin token access: " + (blacklist.isBlacklisted(adminTokenJti) ? "DENIED" : "GRANTED"));
}
}Whitelisting Explained
Whitelisting is an alternative revocation strategy. Instead of listing forbidden tokens, you maintain a list of active, allowed tokens.
- When a token is issued, its JTI is added to a 'whitelist'.
- For every request, the token's JTI must be found on this whitelist to be considered valid.
- If a token's JTI is not on the whitelist, it's rejected.
Implementing a Whitelist
Similar to blacklisting, a whitelist requires a fast, persistent store (e.g., Redis). The key difference is what you store and how you manage it:
- Each entry typically stores the JWT's JTI, often associated with a user ID.
- When a user logs out or changes their password, all active JTIs associated with that user can be efficiently removed from the whitelist.
Blacklist vs. Whitelist Comparison
Both strategies achieve revocation but have different implications:
- Blacklist: Ideal for rare, specific revocations (e.g., single token compromise). Requires less storage if revocations are infrequent.
- Whitelist: Better for frequent revocations (e.g., user logout invalidates all tokens). Can simplify session management but requires more storage for all active tokens.
- The choice depends on your application's specific needs and the frequency of revocations.
Revocation Scenario
Consider an application where users frequently log out, and you need to ensure all their issued tokens are immediately invalidated upon logout.
Recap: Revocation Strategies
In this lesson, we've explored advanced strategies for revoking JWTs, which is crucial for robust security:
- Blacklisting: Marking specific tokens as invalid by adding their JTI to a forbidden list.
- Whitelisting: Only allowing tokens that are explicitly listed as active, often tied to a user session.
- The best approach depends on your application's requirements, especially the frequency and nature of token invalidation.
Next, we'll analyze the performance implications of these techniques.
Ucz się Java dzięki korepetycjom AI — za darmo
Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.
- Kursy
- 12
- Lekcje
- 48
Często zadawane pytania
Czy lekcja „Czarne i białe listy tokenów JWT” jest bezpłatna?
Tak — pełny tekst „Czarne i białe listy tokenów JWT” 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 „Czarne i białe listy tokenów JWT”?
Poznaj zaawansowane techniki unieważniania tokenów, w tym zarządzanie czarnymi lub białymi listami tokenów. Ć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 2 z 4.
Ile czasu zajmuje lekcja „Czarne i białe listy tokenów JWT”?
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
- Tokeny JWT krótkoterminowe i cykl odświeżania
- Czarne i białe listy tokenów JWT
- Aspekty wydajności tokenów JWT
- Buforowanie walidacji tokenów na potrzeby skalowania