code_challenge<\/code> (SHA-256-Hash). Die Challenge wird im Authorization Request mitgesendet. Beim Token-Request schickt der Client den originalen Verifier, den der Server gegen die gespeicherte Challenge verifiziert.<\/p>\n\n\n\nF\u00fcr Custom OAuth-Flows ohne Passport (z. B. bei einem eigenen Authorization Server oder einem Provider der kein Passport-Paket hat) sieht die PKCE-Implementierung in Node.js so aus:<\/p>\n\n\n\n
\/\/ src\/utils\/pkce.js\nconst crypto = require('crypto');\n\nfunction generateCodeVerifier() {\n \/\/ RFC 7636: 43-128 Zeichen, URL-safe Base64 (base64url, kein +, \/, =)\n return crypto.randomBytes(32).toString('base64url');\n}\n\nfunction generateCodeChallenge(codeVerifier) {\n \/\/ Nur S256-Methode verwenden, nie 'plain'\n return crypto.createHash('sha256')\n .update(codeVerifier)\n .digest('base64url');\n}\n\nfunction buildAuthorizationUrl(params) {\n const codeVerifier = generateCodeVerifier();\n const codeChallenge = generateCodeChallenge(codeVerifier);\n const state = crypto.randomBytes(16).toString('hex');\n\n const url = new URL(params.authorizationEndpoint);\n url.searchParams.set('response_type', 'code');\n url.searchParams.set('client_id', params.clientId);\n url.searchParams.set('redirect_uri', params.redirectUri);\n url.searchParams.set('scope', params.scope);\n url.searchParams.set('state', state);\n url.searchParams.set('code_challenge', codeChallenge);\n url.searchParams.set('code_challenge_method', 'S256');\n\n \/\/ codeVerifier und state in Session speichern f\u00fcr sp\u00e4tere Verifizierung\n return { url: url.toString(), codeVerifier, state };\n}\n\nasync function exchangeCodeForToken(params) {\n const body = new URLSearchParams({\n grant_type: 'authorization_code',\n code: params.code,\n redirect_uri: params.redirectUri,\n client_id: params.clientId,\n code_verifier: params.codeVerifier \/\/ Hier wird der Verifier mitgesendet\n });\n\n const response = await fetch(params.tokenEndpoint, {\n method: 'POST',\n headers: { 'Content-Type': 'application\/x-www-form-urlencoded' },\n body: body.toString()\n });\n\n return response.json();\n}\n\nmodule.exports = { generateCodeVerifier, generateCodeChallenge, buildAuthorizationUrl, exchangeCodeForToken };<\/code><\/pre>\n\n\n\nDer code_verifier<\/code> muss serverseitig zwischen Authorization Request und Token Request sicher gespeichert werden, zum Beispiel in der Session. Der SHA-256-Algorithmus (S256<\/code>) ist die einzig zul\u00e4ssige Methode nach aktuellem Stand. Der veraltete plain<\/code>-Modus bietet keinen echten Schutz und darf nicht verwendet werden, da er keinen Schutz vor einem passiven Angreifer bietet, der die PKCE-Parameter mitlesen kann.<\/p>\n\n\n\nSchritt 9: Auth-Middleware und gesch\u00fctzte Routen<\/h2>\n\n\n\n
Eine Middleware pr\u00fcft bei jeder Anfrage das JWT-Access-Token aus dem Cookie und h\u00e4ngt die dekodierten User-Daten an das Request-Objekt. Gesch\u00fctzte Routen verwenden diese Middleware als Guard.<\/p>\n\n\n\n
\/\/ src\/middleware\/auth.js\nconst jwt = require('jsonwebtoken');\n\nasync function authenticateToken(req, res, next) {\n const token = req.cookies?.access_token;\n\n if (!token) {\n return res.status(401).json({ error: 'Kein Token vorhanden' });\n }\n\n try {\n const decoded = jwt.verify(token, process.env.JWT_SECRET, {\n \/\/ Issuer-Validierung verhindert Token-Confusion-Angriffe\n \/\/ issuer: 'https:\/\/deine-app.com' \/\/ In Produktion aktivieren\n });\n req.user = decoded;\n next();\n } catch (err) {\n if (err.name === 'TokenExpiredError') {\n return res.status(401).json({\n error: 'Token abgelaufen',\n code: 'TOKEN_EXPIRED'\n });\n }\n return res.status(403).json({ error: 'Ung\u00fcltiges Token' });\n }\n}\n\nmodule.exports = { authenticateToken };<\/code><\/pre>\n\n\n\n\/\/ src\/routes\/protected.js\nconst express = require('express');\nconst { authenticateToken } = require('..\/middleware\/auth');\nconst router = express.Router();\n\nrouter.get('\/profile', authenticateToken, (req, res) => {\n res.json({\n userId: req.user.userId,\n email: req.user.email,\n name: req.user.name\n });\n});\n\nrouter.get('\/dashboard', authenticateToken, (req, res) => {\n res.json({\n message: `Willkommen, ${req.user.name}`,\n tokenAusgestellt: new Date(req.user.iat * 1000).toISOString(),\n tokenLaeuftAb: new Date(req.user.exp * 1000).toISOString()\n });\n});\n\nmodule.exports = router;<\/code><\/pre>\n\n\n\nDie Middleware unterscheidet explizit zwischen abgelaufenem Token (TokenExpiredError<\/code>) und ung\u00fcltigem Token. Das erm\u00f6glicht dem Client, automatisch ein neues Token anzufordern, wenn der Fehlercode TOKEN_EXPIRED<\/code> zur\u00fcckkommt, ohne den Benutzer zur erneuten Anmeldung zu zwingen. Ung\u00fcltige Tokens (falsche Signatur, manipulierter Payload) werden mit 403 Forbidden<\/code> abgelehnt.<\/p>\n\n\n\nSchritt 10: Refresh-Token-Mechanismus implementieren<\/h2>\n\n\n\n
Access Tokens mit kurzer Laufzeit (5-15 Minuten) erh\u00f6hen die Sicherheit erheblich, da ein kompromittiertes Token nur kurze Zeit nutzbar ist. Refresh Tokens erm\u00f6glichen es, neue Access Tokens zu holen, ohne den Benutzer erneut zur Anmeldung zu zwingen. Die Laufzeit von Refresh Tokens liegt typischerweise bei 7-30 Tagen.<\/p>\n\n\n\n
\/\/ src\/routes\/auth.js (Erweiterung mit Refresh-Endpoint)\nrouter.post('\/refresh', async (req, res) => {\n const refreshToken = req.cookies?.refresh_token;\n\n if (!refreshToken) {\n return res.status(401).json({ error: 'Kein Refresh Token vorhanden' });\n }\n\n try {\n const decoded = jwt.verify(refreshToken, process.env.JWT_SECRET);\n\n \/\/ Neues Access Token mit voller Laufzeit ausstellen\n const newAccessToken = jwt.sign(\n { userId: decoded.userId },\n process.env.JWT_SECRET,\n { expiresIn: process.env.JWT_ACCESS_EXPIRES || '15m' }\n );\n\n res.cookie('access_token', newAccessToken, {\n httpOnly: true,\n secure: process.env.NODE_ENV === 'production',\n sameSite: 'lax',\n maxAge: 15 * 60 * 1000\n });\n\n res.json({ message: 'Token erfolgreich erneuert' });\n\n } catch (err) {\n \/\/ Bei ung\u00fcltigem Refresh Token beide Cookies l\u00f6schen (vollst\u00e4ndiger Logout)\n res.clearCookie('access_token');\n res.clearCookie('refresh_token', { path: '\/auth\/refresh' });\n return res.status(401).json({ error: 'Refresh Token ung\u00fcltig oder abgelaufen' });\n }\n});<\/code><\/pre>\n\n\n\nEin kritischer Aspekt bei der Token-Erneuerung: Race Conditions. Wenn mehrere parallele API-Anfragen gleichzeitig ein abgelaufenes Token erkennen und alle gleichzeitig den Refresh-Endpoint aufrufen, kann das zu Fehlern f\u00fchren (der zweite Refresh-Request schl\u00e4gt fehl, wenn Refresh Token Rotation aktiv ist). In Produktionsumgebungen sollte ein “Single-Flight”-Mechanismus im Client implementiert werden: Nur die erste Anfrage f\u00fchrt den Refresh durch, alle anderen warten auf das Ergebnis.<\/p>\n\n\n\n
Schritt 11: Token-Revokation mit Redis<\/h2>\n\n\n\n
JWTs sind zustandslos: Der Server kann ein ausgestelltes Token nicht direkt invalidieren, bevor es abl\u00e4uft. Das ist ein bekanntes Problem, zum Beispiel nach einem Passwort-Wechsel, nach einer Sicherheitsverletzung oder wenn ein Benutzer sich aktiv abmeldet. Die L\u00f6sung ist eine Token-Blocklist in Redis, die revozierte Tokens bis zu ihrer Ablaufzeit speichert. Der Speicherbedarf ist gering, da Eintr\u00e4ge automatisch nach Ablauf der Token-TTL entfernt werden.<\/p>\n\n\n\n
\/\/ src\/config\/redis.js\nconst Redis = require('ioredis');\n\nconst redis = new Redis(process.env.REDIS_URL || 'redis:\/\/localhost:6379', {\n lazyConnect: true,\n maxRetriesPerRequest: 3\n});\n\nredis.on('error', (err) => {\n console.error('Redis-Verbindungsfehler:', err.message);\n});\n\nredis.on('connect', () => {\n console.log('Redis verbunden');\n});\n\nasync function revokeToken(token, expiresAt) {\n const secondsUntilExpiry = Math.floor(expiresAt - Date.now() \/ 1000);\n if (secondsUntilExpiry > 0) {\n \/\/ Token bis zu seinem nat\u00fcrlichen Ablauf auf Blocklist setzen\n await redis.set(`revoked:${token}`, '1', 'EX', secondsUntilExpiry);\n }\n}\n\nasync function isTokenRevoked(token) {\n const result = await redis.get(`revoked:${token}`);\n return result !== null;\n}\n\nmodule.exports = { redis, revokeToken, isTokenRevoked };<\/code><\/pre>\n\n\n\nDie Auth-Middleware wird um eine Redis-Pr\u00fcfung erweitert:<\/p>\n\n\n\n
\/\/ src\/middleware\/auth.js (erweitert mit Redis-Blocklist)\nconst jwt = require('jsonwebtoken');\nconst { isTokenRevoked } = require('..\/config\/redis');\n\nasync function authenticateToken(req, res, next) {\n const token = req.cookies?.access_token;\n\n if (!token) {\n return res.status(401).json({ error: 'Kein Token vorhanden' });\n }\n\n try {\n \/\/ Zuerst Blocklist pr\u00fcfen (vor JWT-Verify f\u00fcr schnelles Fail)\n const revoked = await isTokenRevoked(token);\n if (revoked) {\n return res.status(401).json({ error: 'Token revoziert' });\n }\n\n const decoded = jwt.verify(token, process.env.JWT_SECRET);\n req.user = decoded;\n next();\n } catch (err) {\n if (err.name === 'TokenExpiredError') {\n return res.status(401).json({ error: 'Token abgelaufen', code: 'TOKEN_EXPIRED' });\n }\n return res.status(403).json({ error: 'Ung\u00fcltiges Token' });\n }\n}\n\nmodule.exports = { authenticateToken };<\/code><\/pre>\n\n\n\nDie TTL des Redis-Eintrags entspricht der verbleibenden Token-Laufzeit. Redis l\u00f6scht den Eintrag automatisch, sobald das Token ohnehin abgelaufen w\u00e4re. Das h\u00e4lt die Redis-Datenbank sauber und der Speicherbedarf der Blocklist w\u00e4chst nicht unkontrolliert. F\u00fcr Redis-Betrieb in lokaler Entwicklung reicht ein Docker-Befehl: docker run -p 6379:6379 redis:alpine<\/code>.<\/p>\n\n\n\nSchritt 12: Client Credentials Flow f\u00fcr Server-zu-Server-APIs<\/h2>\n\n\n\n
Wenn zwei Server miteinander kommunizieren (z. B. ein Microservice ruft einen anderen auf) und kein Benutzer beteiligt ist, kommt der Client Credentials Flow zum Einsatz. Dieser Flow ben\u00f6tigt kein PKCE und keine Redirect URI, da kein Authorization Code ausgetauscht wird. Der Client sendet Client-ID und Client-Secret direkt an den Token-Endpoint und erh\u00e4lt ein Access Token zur\u00fcck.<\/p>\n\n\n\n
\/\/ src\/services\/clientCredentials.js\nasync function getClientCredentialsToken(config) {\n const body = new URLSearchParams({\n grant_type: 'client_credentials',\n client_id: config.clientId,\n client_secret: config.clientSecret,\n scope: config.scope || ''\n });\n\n const response = await fetch(config.tokenEndpoint, {\n method: 'POST',\n headers: {\n 'Content-Type': 'application\/x-www-form-urlencoded'\n },\n body: body.toString()\n });\n\n if (!response.ok) {\n const error = await response.json();\n throw new Error(`Token-Request fehlgeschlagen: ${error.error_description || error.error}`);\n }\n\n const tokenData = await response.json();\n\n return {\n accessToken: tokenData.access_token,\n tokenType: tokenData.token_type,\n expiresIn: tokenData.expires_in, \/\/ Sekunden bis Ablauf\n expiresAt: Date.now() + (tokenData.expires_in * 1000)\n };\n}\n\n\/\/ Token-Cache um unn\u00f6tige Anfragen zu vermeiden\nlet cachedToken = null;\n\nasync function getValidToken(config) {\n if (cachedToken && cachedToken.expiresAt > Date.now() + 60000) {\n return cachedToken.accessToken; \/\/ 60 Sekunden Puffer vor Ablauf\n }\n cachedToken = await getClientCredentialsToken(config);\n return cachedToken.accessToken;\n}\n\nmodule.exports = { getClientCredentialsToken, getValidToken };<\/code><\/pre>\n\n\n\nDer Token-Cache verhindert unn\u00f6tige Anfragen an den Token-Endpoint. Das Token wird 60 Sekunden vor seinem Ablauf als ung\u00fcltig betrachtet (Puffer), damit kein Request mit einem fast-abgelaufenen Token starte. In Produktionsumgebungen mit mehreren Server-Instanzen sollte der Cache in Redis gespeichert werden, um Token-Endpoint-Anfragen \u00fcber alle Instanzen zu reduzieren.<\/p>\n\n\n\n
Ausgabe-Beispiele: Erwartetes Verhalten<\/h2>\n\n\n\n
Nach vollst\u00e4ndiger Implementierung liefern die Endpoints folgende Ausgaben:<\/p>\n\n\n\n
# Erfolgreicher Login nach OAuth-Callback\nGET \/auth\/google\/callback?code=4\/P7q7W91a...&state=abc123\nHTTP 200 OK\nSet-Cookie: access_token=eyJhbGciOiJIUzI1NiJ9...; HttpOnly; SameSite=Lax\nSet-Cookie: refresh_token=eyJhbGciOiJIUzI1NiJ9...; HttpOnly; Path=\/auth\/refresh\n{\n \"message\": \"Authentifizierung erfolgreich\",\n \"user\": {\n \"email\": \"benutzer@gmail.com\",\n \"name\": \"Max Mustermann\"\n }\n}\n\n# Gesch\u00fctzte Route mit g\u00fcltigem Token\nGET \/api\/profile\nCookie: access_token=eyJhbGciOiJIUzI1NiJ9...\nHTTP 200 OK\n{\n \"userId\": \"116029571234567890\",\n \"email\": \"benutzer@gmail.com\",\n \"name\": \"Max Mustermann\"\n}\n\n# Gesch\u00fctzte Route ohne Token\nGET \/api\/profile\nHTTP 401 Unauthorized\n{ \"error\": \"Kein Token vorhanden\" }\n\n# Abgelaufenes Token\nGET \/api\/profile\nCookie: access_token=eyJhbGciOiJIUzI1NiJ9... (15 min vergangen)\nHTTP 401 Unauthorized\n{ \"error\": \"Token abgelaufen\", \"code\": \"TOKEN_EXPIRED\" }\n\n# Token-Refresh\nPOST \/auth\/refresh\nCookie: refresh_token=eyJhbGciOiJIUzI1NiJ9...\nHTTP 200 OK\nSet-Cookie: access_token=eyJhbGciOiJIUzI1NiJ9...(neu); HttpOnly\n{ \"message\": \"Token erfolgreich erneuert\" }<\/code><\/pre>\n\n\n\n5 h\u00e4ufige Fehler bei der OAuth 2.0-Implementierung<\/h2>\n\n\n\n
Diese Fallstricke begegnen Entwicklern am h\u00e4ufigsten beim Implementieren von OAuth 2.0 in Node.js:<\/p>\n\n\n\n
Fehler 1: Tokens in localStorage speichern<\/h3>\n\n\n\n
Problem:<\/strong> Viele Tutorials empfehlen, Access Tokens im Browser-localStorage oder sessionStorage zu speichern. Das ist gef\u00e4hrlich, weil JavaScript jeder Herkunft auf localStorage zugreifen kann. Ein einziger XSS-Angriff reicht, um alle gespeicherten Tokens zu stehlen, und der Angreifer kann die Tokens dann von einem eigenen Server aus verwenden.<\/p>\n\n\n\nL\u00f6sung:<\/strong> Tokens ausschlie\u00dflich als httpOnly<\/code>-Cookies setzen. JavaScript kann auf httpOnly-Cookies grunds\u00e4tzlich nicht zugreifen, auch nicht bei XSS. Die Cookie-Konfiguration in diesem Tutorial zeigt den korrekten Ansatz. Das Muster mit Two-Factor Authentication<\/a> kombiniert erh\u00f6ht die Sicherheit weiter.<\/p>\n\n\n\nFehler 2: State-Parameter weglassen<\/h3>\n\n\n\n
Problem:<\/strong> Ohne den state<\/code>-Parameter ist der OAuth-Flow anf\u00e4llig f\u00fcr CSRF-Angriffe. Ein Angreifer k\u00f6nnte einen Benutzer dazu bringen, einen Authorization Code zu aktivieren, der dann an den Angreifer-Account gebunden wird (“Login CSRF”). Das ist ein reales Angriffsszenario mit dokumentierten Vorf\u00e4llen.<\/p>\n\n\n\nL\u00f6sung:<\/strong> Immer einen kryptographisch zuf\u00e4lligen state<\/code>-Parameter im Authorization Request mitsenden und im Callback gegen den gespeicherten Wert verifizieren. Passport.js \u00fcbernimmt das automatisch mit state: true<\/code>. Bei custom Implementierungen muss das explizit mit crypto.randomBytes(16).toString('hex')<\/code> generiert werden.<\/p>\n\n\n\nFehler 3: Redirect URI zu gro\u00dfz\u00fcgig konfigurieren<\/h3>\n\n\n\n
Problem:<\/strong> Manche Entwickler registrieren Wildcards als Redirect URI (https:\/\/app.com\/*<\/code>) oder verwenden Regex-Matching, wenn der Authorization Server das anbietet. Das erm\u00f6glicht es einem Angreifer, den Authorization Code an eine beliebige URL unter der Domain umzuleiten.<\/p>\n\n\n\nL\u00f6sung:<\/strong> Redirect URIs immer als exakte Strings registrieren und aus Umgebungsvariablen laden. F\u00fcr Entwicklung und Produktion separate, exakte URIs in der Providerkonsole eintragen. Der Authorization Server soll String-Matching ohne Pattern-Unterst\u00fctzung erzwingen, wie es OAuth 2.1 vorschreibt.<\/p>\n\n\n\nFehler 4: Google-Tokens direkt als App-Tokens verwenden<\/h3>\n\n\n\n
Problem:<\/strong> Der von Google erhaltene Access Token wird direkt an den Browser weitergegeben und f\u00fcr API-Anfragen verwendet. Das erzeugt eine starke Abh\u00e4ngigkeit von Google, und der Token hat Googles eigene Laufzeit und Scopes, nicht die der App. Au\u00dferdem kann der Token nicht kontrolliert revoziert werden.<\/p>\n\n\n\nL\u00f6sung:<\/strong> Nach erfolgreichem OAuth-Handshake eigene JWTs ausstellen (wie in Schritt 7 gezeigt). Der Google-Token wird nur beim Login verwendet, um die Identit\u00e4t zu pr\u00fcfen. Danach arbeitet die App ausschlie\u00dflich mit eigenen Tokens, die volle Kontrolle \u00fcber Laufzeit, Scopes und Revokation bieten.<\/p>\n\n\n\nFehler 5: Refresh Token f\u00fcr jeden Benutzer mehrfach ausstellen<\/h3>\n\n\n\n
Problem:<\/strong> Wenn bei jedem Login ein neuer Refresh Token ausgestellt wird ohne den alten zu invalidieren, k\u00f6nnen sich im Laufe der Zeit viele g\u00fcltige Refresh Tokens f\u00fcr denselben Benutzer ansammeln. Ein gestohlener Token bleibt dauerhaft g\u00fcltig, selbst wenn sich der Benutzer neu anmeldet.<\/p>\n\n\n\nL\u00f6sung:<\/strong> Refresh Token Rotation implementieren: Bei jedem Einsatz eines Refresh Tokens wird ein neues Refresh Token ausgestellt und das alte in der Blocklist gespeichert. Wenn ein bereits invalidierter Refresh Token verwendet wird, deutet das auf Token-Diebstahl hin, und alle Sessions des Benutzers werden gesperrt.<\/p>\n\n\n\n