Om een efficiënt JWT-token intrekkingsmechanisme voor je REST API te ontwerpen, kun je de volgende benadering overwegen: 1. Gebruik van een Blacklist met korte levensduur: - Maintain een blacklist van JWT-tokens die zijn ingetrokken of ongeldig verklaard. - Wanneer een gebruiker uitlogt, voeg je het token (bijvoorbeeld op basis van een unieke identifier zoals de jti (JWT ID) claim) toe aan de blacklist. - Controleer bij elke API-aanvraag of het token op de blacklist staat. - Voordeel: Eenvoudig te implementeren en effectief voor directe intrekking. - Nadelen: De blacklist moet in een snelle dataopslag zoals Redis worden opgeslagen om de prestaties niet te schaden. 2. Gebruik van een Token Versioning (versiebeheer): - Voeg een versieveld toe aan de gebruiker in je database (bijvoorbeeld `token_version`). - Bij het genereren van een token, embed de huidige `token_version` in de payload. - Bij elke authenticatie controleer je of de `token_version` in het token overeenkomt met die in de database. - Bij uitloggen of intrekking, verhoog je de `token_version` in de database. - Voordeel: Geen blacklist nodig, alleen een eenvoudige versiecontrole. - Nadelen: Vereist dat je de versies efficiënt beheert en controleert. 3. Combineer methodes: - Gebruik een korte levensduur voor tokens (bijvoorbeeld 1 uur). - Bij uitloggen zet je de `token_version` of markeer je het token als ingetrokken in een snelle cache. - Bij verificatie controleer je zowel de geldigheid als de versie of blacklist. 4. Overwegingen voor prestaties: - Gebruik in-memory databases zoals Redis voor blacklist en token versiecontrole om snelle toegang te garanderen. - Minimaliseer de hoeveelheid gegevens die je bij elke verificatie moet controleren. - Overweeg om refresh tokens te gebruiken: gebruik een lange levensduur voor refresh tokens en korte voor access tokens. Bij uitloggen vervang je de refresh token, zodat oude access tokens automatisch verlopen. Samenvatting: - Voor directe intrekking bij uitloggen is een blacklist of token versiebeheer effectief. - Blacklist: voeg ingetrokken tokens toe aan Redis en controleer bij elke request. - Token versioning: verhoog de versie in de database bij uitloggen en controleer deze in het token. - Gebruik korte levensduur en refresh tokens voor betere controle en prestatiebalans. Door deze methoden te combineren en gebruik te maken van snelle dataopslag, houd je de prestaties van je authenticatiesysteem optimaal.

Zeker, hier is een efficiënt ontwerp voor JWT-intrekking voor uw REST API, met aandacht voor prestaties en directe intrekking bij uitloggen. ### Aanbevolen Aanpak: Gedistribueerde Blacklist (Blocklist) met Korte TTL Gezien uw vereiste voor **directe intrekking** en een tokenlevensduur van slechts **1 uur**, is een blacklist (beter bekend als een blocklist) de meest praktische en directe oplossing. De korte levensduur van het token is hier een groot voordeel. ### Kerncomponenten van het Ontwerp #### 1. Blocklist Storage: Redis Gebruik **Redis** als uw blocklist-datastore. Redis is een in-memory datastructuurstore, ideaal voor dit scenario vanwege: * **Extreem lage latentie** (microseconden). * **Ingebouwde ondersteuning voor TTL (Time-To-Live)**: Je kunt de geblokkeerde token automatisch laten verlopen wanneer het oorspronkelijke JWT-token zou zijn verlopen. * **Eenvoudige sleutel-waardestructuur**. #### 2. Token Identifier: JTI (JWT ID) Elk uitgegeven JWT moet een unieke identifier bevatten in de `jti` (JWT ID) claim. Genereer deze willekeurig (bijv. een UUID) wanneer het token wordt aangemaakt. ```json { "sub": "1234567890", "name": "John Doe", "iat": 1516239022, "exp": 1516242622, // 1 uur later "jti": "a1b2c3d4-e5f6-7890-abcd-ef1234567890" // <-- Unieke ID } ``` #### 3. Integratie in uw Authenticatiestroom **a. Bij Uitgeven (Login):** 1. Genereer een JWT met een `exp` (1 uur) en een unieke `jti`. 2. Sla de `jti` *niet* standaard op in een database. Alleen ingetrokken tokens krijgen een record. **b. Bij Intrekken (Uitloggen / Wachtwoordwijziging):** 1. Wanneer een gebruiker uitlogt, ontvangt je API de nog geldige JWT (meestal via een Authorization header). 2. Verifieer de handtekening en valideer de `exp` claim van het token. 3. **Voeg de `jti` van het token toe aan de Redis blocklist. Stel de TTL in Redis gelijk aan de resterende levensduur van het token.** ```bash # Redis commando (voorbeeld) SETEX token_blocklist:a1b2c3d4-e5f6-7890-abcd-ef1234567890 1800 "revoked" # '1800' is de TTL in seconden (30 minuten, als er nog 30 minuten resteren) ``` *Dit minimaliseert de geheugengebruik in Redis, omdat records automatisch worden opgeruimd.* **c. Bij Elke Authenticatieverzoek (API Request):** 1. Ontvang het JWT van de client en verifieer eerst de handtekening met je publieke geheim/sleutel. 2. Valideer de standaardclaims (`exp`, `iat`). Een verlopen token wordt direct geweigerd. 3. **Voordat de request wordt toegestaan, check je de blocklist:** * Haal de `jti` claim uit het JWT. * Doe een **snelle lookup** in Redis om te controleren of deze `jti` aanwezig is in de blocklist. ```javascript // Pseudocode voor je middleware const token = getTokenFromHeader(request); const decoded = verify(token, secret); if (decoded.exp < Date.now() / 1000) { throw new Error('Token expired'); } // PERFORMANCE-CRITICAL STAP: Check Redis blocklist const isRevoked = await redisClient.get(`token_blocklist:${decoded.jti}`); if (isRevoked) { throw new Error('Token revoked'); } // Token is geldig, ga verder met de request next(); ``` ### Prestatieoverwegingen en Optimalisaties * **Snelheid:** Een Redis lookup is een eenvoudige `GET` operatie en is ontzettend snel (vaak < 1ms). Dit voegt minimale overhead toe aan elk verzoek. * **Schaalbaarheid:** Redis is gebouwd voor hoge doorvoer en kan eenvoudig worden geschaald (Redis Cluster) als je applicatie groeit. * **Geheugenbeheer:** Door de TTL in Redis gelijk te stellen aan de resterende levensduur van het token, verwijdert Redis records automatisch. Je blocklist blijft compact en bevat alleen tokens die technisch gezien nog geldig *zouden kunnen* zijn. * **Caching Laag:** Je authenticatiemiddleware kan een zeer korte-lived in-memory cache (lokaal of gedeeld zoals Redis weer) houden voor veelvoorkomende `jti` checks om herhaalde lookups voor dezelfde token (bijv. bij meerdere requests van dezelfde gebruiker in korte tijd) te voorkomen. ### Alternatieven en Waarom Ze Minder Geschikt Zijn * **Whitelist (Allowlist):** Hier sla je *alle* uitgegeven `jti`-waarden op in een database en check je of het token bestaat. Dit is **niet aan te raden** omdat: * Het de database enorm laat groeien (elk login verzoek creëert een record). * Je een cleanup job nodig hebt om verlopen tokens te verwijderen. * Het veel trager is dan een blocklist die alleen een kleine subset van tokens bevat. * **Token Versiebeheer:** Je slaat een tokenversie (bijv. `token_version`) op in de gebruikerstabel en in de JWT. Bij uitloggen verhoog je de versie in de database. Bij elke request vergelijk je de versie in de JWT met die in de database. * **Nadeel:** Vereist een **database query bij elk authenticatieverzoek** om de gebruikersrecord op te halen. Dit is doorgaans **aanzienlijk langzamer** dan een Redis `GET`-opdracht en legt een grotere belasting op je primaire database. Dit schaalt minder goed. ### Conclusie en Aanbeveling Voor uw use case (**REST API, 1u TTL, directe intrekking**) is de **Redis Blocklist met JTI en TTL** de meest efficiënte en eenvoudig te implementeren oplossing. **Samenvattend actieplan:** 1. Integreer Redis in uw infrastructuur. 2. Wijzig uw JWT-uitgifte om een unieke `jti` (UUID) te genereren. 3. Implementeer een logout endpoint dat de `jti` van het huidige token ophaalt en deze met TTL toevoegt aan Redis. 4. Schrijf authenticatiemiddleware die na de standaard JWT-validatie een check tegen de Redis blocklist uitvoert. 5. (Optioneel) Overweeg een eenvoudige cache voor herhaalde `jti`-lookups in de middleware. Dit ontwerp biedt de directe intrekking die u nodig heeft, met een verwaarloosbare impact op de prestaties van uw authenticatiesysteem.