{"id":134,"date":"2026-06-14T20:21:02","date_gmt":"2026-06-14T20:21:02","guid":{"rendered":"https:\/\/shattered.io\/de\/2026\/06\/14\/oauth-pkce-nodejs\/"},"modified":"2026-06-14T20:22:23","modified_gmt":"2026-06-14T20:22:23","slug":"oauth-pkce-nodejs","status":"publish","type":"post","link":"https:\/\/shattered.io\/de\/2026\/06\/14\/oauth-pkce-nodejs\/","title":{"rendered":"OAuth 2.1 mit PKCE in Node.js: 12 Schritte [2026]"},"content":{"rendered":"\n

OAuth<\/strong> ist 2026 der De-facto-Standard, wenn sich Nutzer per Google, Microsoft oder einem eigenen Identity-Provider an einer Web-App anmelden sollen. Doch der klassische Authorization Code Flow allein reicht nicht mehr. Mit OAuth 2.1 wird PKCE (Proof Key for Code Exchange) f\u00fcr jeden Authorization-Code-Flow verpflichtend, auch f\u00fcr klassische Server-Apps. Dieses Tutorial zeigt in 12 Schritten, wie Sie einen sicheren OAuth-Login mit PKCE in Node.js und Express von Grund auf bauen. Planen Sie rund 45 Minuten ein. Am Ende l\u00e4uft ein vollst\u00e4ndiges, funktionsf\u00e4higes Projekt.<\/p>\n\n\n\n

Wir arbeiten mit Node.js 24 (LTS), Express 5 und nativem crypto<\/code>-Modul. Erst bauen wir den Flow manuell, damit Sie jeden Schritt verstehen. Danach zeigen wir die kompakte Variante mit der Bibliothek openid-client<\/code>. Jeder Codeblock ist getestet, jede Version stammt aus der offiziellen npm-Registry (Stand Juni 2026).<\/p>\n\n\n\n

Was sich mit OAuth 2.1 und PKCE 2026 \u00e4ndert<\/h2>\n\n\n\n

OAuth 2.0 (RFC 6749) stammt aus dem Jahr 2012. Seitdem haben Sicherheitsforscher zahlreiche Angriffsmuster dokumentiert, von Authorization-Code-Interception bis zu offenen Redirects. OAuth 2.1 ist kein neues Protokoll, sondern eine Konsolidierung: Es fasst die bew\u00e4hrten Sicherheitspraktiken aus \u00fcber einem Jahrzehnt zusammen und streicht alles, was sich als gef\u00e4hrlich erwiesen hat. Der Entwurf befindet sich noch im IETF-Prozess, doch gro\u00dfe Anbieter wie Google, Microsoft und Okta setzen die Vorgaben bereits um.<\/p>\n\n\n\n

Die drei wichtigsten \u00c4nderungen betreffen jeden Entwickler. Erstens: PKCE (RFC 7636) ist f\u00fcr alle Authorization-Code-Flows Pflicht, nicht mehr nur f\u00fcr mobile und Single-Page-Apps. Zweitens: Der Implicit Flow (response_type=token<\/code>) f\u00e4llt komplett weg, weil er Access Tokens ungesch\u00fctzt \u00fcber die URL ausliefert. Drittens: Der Resource Owner Password Credentials Grant, bei dem die App das Klartext-Passwort des Nutzers entgegennimmt, ist gestrichen. Damit bleibt f\u00fcr Web-Apps praktisch nur noch ein sicherer Weg: der Authorization Code Flow mit PKCE.<\/p>\n\n\n\n

F\u00fcr die DACH-Region hat das konkrete Folgen. Die NIS2-Richtlinie und der Cyber Resilience Act verlangen risikobasierte technische Ma\u00dfnahmen, darunter starke Zugriffskontrollen und nachvollziehbare Authentifizierung. Ein OAuth-Login, der PKCE und korrekte Token-Validierung umsetzt, erf\u00fcllt diese Anforderung an der Schnittstelle zwischen Nutzer und Anwendung. Wer noch Implicit Flow oder Passwort-Grant einsetzt, l\u00e4uft 2026 in ein Compliance-Problem. Identit\u00e4tssicherheit geh\u00f6rt laut den aktuellen DACH-Sicherheitsberichten zu den am st\u00e4rksten beachteten Themen, getrieben durch organisierte Cybercrime-Gruppen und KI-gest\u00fctzte Phishing-Angriffe.<\/p>\n\n\n\n

Merkmal<\/th>OAuth 2.0 (2012)<\/th>OAuth 2.1 (2026)<\/th><\/tr><\/thead>
PKCE<\/td>optional (nur Public Clients)<\/td>Pflicht f\u00fcr alle Code-Flows<\/td><\/tr>
Implicit Flow<\/td>erlaubt<\/td>entfernt<\/td><\/tr>
Password Grant<\/td>erlaubt<\/td>entfernt<\/td><\/tr>
Refresh Tokens<\/td>frei rotierbar<\/td>Rotation oder Sender-Binding empfohlen<\/td><\/tr>
Redirect URI<\/td>teils Wildcards<\/td>exakter String-Vergleich<\/td><\/tr>
Bearer Token in URL<\/td>geduldet<\/td>verboten<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Voraussetzungen: Node.js 24, Express 5 und die richtigen Pakete<\/h2>\n\n\n\n

Bevor Sie loslegen, pr\u00fcfen Sie Ihre Umgebung. Dieses Tutorial setzt auf die aktuellen LTS-Versionen vom Juni 2026. Node.js 24 ist die aktive LTS-Linie, Node.js 26 l\u00e4uft als Current und ist noch nicht f\u00fcr Produktion empfohlen. Express ist mit Version 5 ein gro\u00dfer Sprung gegen\u00fcber dem jahrelang stabilen Express 4, vor allem beim Promise-Handling in Routen.<\/p>\n\n\n\n

Pr\u00fcfen Sie Ihre Node-Version mit node --version<\/code>. Sie sollten v24.x<\/code> oder h\u00f6her sehen. Falls nicht, installieren Sie die LTS \u00fcber den offiziellen Installer oder einen Versionsmanager wie nvm<\/code> oder fnm<\/code>. Die folgende Tabelle listet jede Abh\u00e4ngigkeit mit der zum Redaktionsschluss aktuellen Version aus der npm-Registry.<\/p>\n\n\n\n

Paket \/ Tool<\/th>Version (Juni 2026)<\/th>Zweck<\/th><\/tr><\/thead>
Node.js<\/td>24.x LTS<\/td>Laufzeitumgebung, natives crypto<\/td><\/tr>
express<\/td>5.2.1<\/td>HTTP-Server und Routing<\/td><\/tr>
express-session<\/td>1.19.0<\/td>Server-seitige Sessions<\/td><\/tr>
helmet<\/td>8.2.0<\/td>sichere HTTP-Header<\/td><\/tr>
openid-client<\/td>6.8.4<\/td>OAuth\/OIDC-Bibliothek (Teil 2)<\/td><\/tr>
passport<\/td>0.7.0<\/td>optionale Auth-Middleware<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Sie brauchen au\u00dferdem einen OAuth-Provider mit registrierter Anwendung. F\u00fcr dieses Tutorial nutzen wir Google als Beispiel, weil sich dort kostenlos eine OAuth-Client-ID anlegen l\u00e4sst. Legen Sie in der Google Cloud Console ein OAuth-2.0-Client-ID-Projekt vom Typ “Web application” an und tragen Sie als Redirect URI exakt http:\/\/localhost:3000\/callback<\/code> ein. Notieren Sie Client-ID und Client-Secret. Der Flow funktioniert mit jedem standardkonformen Provider identisch, nur die Endpunkt-URLs \u00e4ndern sich.<\/p>\n\n\n\n

Der Authorization Code Flow mit PKCE im Detail<\/h2>\n\n\n\n

Bevor wir Code schreiben, lohnt sich ein klarer Blick auf den Ablauf. Der Flow hat zwei zentrale Endpunkte beim Provider. Der Authorization Endpoint nimmt die Anfrage entgegen, an der sich der Nutzer einloggt und seine Zustimmung gibt. Der Token Endpoint tauscht den zur\u00fcckgegebenen Code gegen die eigentlichen Tokens. PKCE schiebt dazwischen einen kryptografischen Beweis, der verhindert, dass ein abgefangener Code missbraucht werden kann.<\/p>\n\n\n\n

Der Ablauf in der Reihenfolge der Ereignisse: Ihre App erzeugt einen zuf\u00e4lligen code_verifier<\/code> und leitet daraus per SHA-256 die code_challenge<\/code> ab. Die App schickt den Nutzer mit der Challenge zum Authorization Endpoint. Der Nutzer loggt sich beim Provider ein. Der Provider leitet zur\u00fcck zur Redirect URI und \u00fcbergibt einen einmaligen code<\/code>. Ihre App ruft den Token Endpoint auf und schickt diesen Code zusammen mit dem urspr\u00fcnglichen code_verifier<\/code>. Der Provider hasht den Verifier erneut, vergleicht ihn mit der gespeicherten Challenge und gibt nur bei \u00dcbereinstimmung die Tokens heraus.<\/p>\n\n\n\n

Der Clou: Der code_verifier<\/code> verl\u00e4sst nie den Browser-Umweg, sondern geht nur \u00fcber den direkten, server-zu-server gesicherten Token-Request. Selbst wenn ein Angreifer den code<\/code> aus der Redirect-URL abf\u00e4ngt, fehlt ihm der Verifier, und der Token-Austausch scheitert. Das ist der gesamte Sicherheitsgewinn von PKCE in einem Satz.<\/p>\n\n\n\n

Schritt 1 und 2: Projekt initialisieren und Pakete installieren<\/h2>\n\n\n\n

Legen Sie ein neues Verzeichnis an und initialisieren Sie das Projekt. Wir nutzen ES-Module, deshalb setzen wir \"type\": \"module\"<\/code> in der package.json<\/code>. F\u00fcr den ersten Teil brauchen wir nur drei Laufzeit-Pakete, denn den OAuth-Flow bauen wir bewusst mit nativen Node-Mitteln.<\/p>\n\n\n\n

# Schritt 1: Projekt anlegen\nmkdir oauth-pkce-node && cd oauth-pkce-node\nnpm init -y\nnpm pkg set type=module\n\n# Schritt 2: Abh\u00e4ngigkeiten installieren\nnpm install express@5.2.1 express-session@1.19.0 helmet@8.2.0\n\n# Versionen pr\u00fcfen\nnode --version          # erwartet: v24.x\nnpm ls --depth=0<\/code><\/pre>\n\n\n\n
Erstellen Sie als N\u00e4chstes eine .env<\/code>-Datei f\u00fcr die Geheimnisse. Niemals geh\u00f6ren Client-ID und Secret direkt in den Quellcode, denn dann landen sie fr\u00fcher oder sp\u00e4ter im Git-Repository. Node.js 24 liest .env<\/code>-Dateien nativ \u00fcber das Flag --env-file<\/code>, ganz ohne Zusatzpaket wie dotenv<\/code>.<\/p>\n\n\n\n
# .env (niemals committen, in .gitignore aufnehmen)\nOAUTH_CLIENT_ID=ihre-client-id.apps.googleusercontent.com\nOAUTH_CLIENT_SECRET=ihr-client-secret\nOAUTH_REDIRECT_URI=http:\/\/localhost:3000\/callback\nSESSION_SECRET=ein-langes-zufaelliges-geheimnis-mind-32-zeichen\nAUTH_ENDPOINT=https:\/\/accounts.google.com\/o\/oauth2\/v2\/auth\nTOKEN_ENDPOINT=https:\/\/oauth2.googleapis.com\/token<\/code><\/pre>\n\n\n\n
Tragen Sie .env<\/code> sofort in Ihre .gitignore<\/code> ein. Ein versehentlich ver\u00f6ffentlichtes Client-Secret ist einer der h\u00e4ufigsten Gr\u00fcnde f\u00fcr kompromittierte OAuth-Apps. Provider erlauben zwar das Rotieren von Secrets, doch der Schaden durch ein geleaktes Secret kann in Minuten entstehen.<\/p>\n\n\n\n
Schritt 3 und 4: Express-Server und sichere Sessions<\/h2>\n\n\n\n
Jetzt bauen wir das Grundger\u00fcst. Wir starten Express, aktivieren Helmet f\u00fcr sichere HTTP-Header und konfigurieren express-session<\/code>. Die Session ist hier entscheidend, denn wir m\u00fcssen den code_verifier<\/code> und den state<\/code>-Parameter zwischen dem Authorization Request und dem Callback zwischenspeichern. Diese Werte geh\u00f6ren server-seitig in die Session, nicht in versteckte Formularfelder oder Cookies, die der Client manipulieren k\u00f6nnte.<\/p>\n\n\n\n
\/\/ server.js\nimport express from 'express';\nimport session from 'express-session';\nimport helmet from 'helmet';\nimport crypto from 'node:crypto';\n\nconst app = express();\napp.use(helmet());\napp.use(express.urlencoded({ extended: false }));\n\n\/\/ Schritt 4: Session-Konfiguration mit sicheren Cookie-Flags\napp.use(session({\n  secret: process.env.SESSION_SECRET,\n  resave: false,\n  saveUninitialized: false,\n  cookie: {\n    httpOnly: true,        \/\/ kein Zugriff per JavaScript\n    secure: false,         \/\/ in Produktion: true (nur HTTPS)\n    sameSite: 'lax',       \/\/ erlaubt den Redirect-Callback\n    maxAge: 10 * 60 * 1000 \/\/ 10 Minuten\n  }\n}));\n\napp.listen(3000, () => {\n  console.log('Server laeuft auf http:\/\/localhost:3000');\n});<\/code><\/pre>\n\n\n\n
Die Cookie-Flags verdienen Aufmerksamkeit. httpOnly<\/code> sperrt den Zugriff per JavaScript und sch\u00fctzt vor XSS-basiertem Session-Diebstahl. secure<\/code> sorgt daf\u00fcr, dass das Cookie nur \u00fcber HTTPS \u00fcbertragen wird. Lokal arbeiten wir \u00fcber HTTP, deshalb steht es hier auf false<\/code>, in Produktion muss es zwingend auf true<\/code>. sameSite: 'lax'<\/code> ist f\u00fcr OAuth wichtig: Der Callback ist eine seiten\u00fcbergreifende Navigation vom Provider zur\u00fcck zu Ihrer App, und strict<\/code> w\u00fcrde das Session-Cookie dabei unterdr\u00fccken.<\/p>\n\n\n\n
Starten Sie den Server testweise mit node --env-file=.env server.js<\/code>. Erscheint die Meldung “Server laeuft”, steht das Fundament. Den Fehler “Cannot read properties of undefined” an dieser Stelle l\u00f6st fast immer ein fehlendes --env-file<\/code>-Flag aus.<\/p>\n\n\n\n
Schritt 5: PKCE code_verifier und code_challenge erzeugen<\/h2>\n\n\n\n
Das Herzst\u00fcck. Der code_verifier<\/code> ist eine kryptografisch zuf\u00e4llige Zeichenkette mit 43 bis 128 Zeichen aus dem unreservierten URL-Alphabet. Die code_challenge<\/code> entsteht, indem wir den Verifier per SHA-256 hashen und das Ergebnis als base64url ohne Padding kodieren. Diese Methode hei\u00dft im Protokoll S256<\/code> und ist die einzige, die OAuth 2.1 empfiehlt. Die schw\u00e4chere Variante plain<\/code> \u00fcbergibt den Verifier ungehasht und bietet keinen Schutz.<\/p>\n\n\n\n
\/\/ pkce.js\nimport crypto from 'node:crypto';\n\n\/\/ base64url ohne Padding gemaess RFC 7636\nfunction base64url(buffer) {\n  return buffer.toString('base64')\n    .replace(\/\\+\/g, '-')\n    .replace(\/\\\/\/g, '_')\n    .replace(\/=+$\/, '');\n}\n\n\/\/ 32 Zufallsbytes ergeben 43 base64url-Zeichen (Minimum)\nexport function createVerifier() {\n  return base64url(crypto.randomBytes(32));\n}\n\n\/\/ code_challenge = base64url( SHA-256( code_verifier ) )\nexport function createChallenge(verifier) {\n  const hash = crypto.createHash('sha256').update(verifier).digest();\n  return base64url(hash);\n}<\/code><\/pre>\n\n\n\n
Ein kurzer Test zeigt das Ergebnis. Mit crypto.randomBytes(32)<\/code> erhalten wir 256 Bit Entropie, kodiert als 43-Zeichen-String, also exakt am unteren Limit der Spezifikation. Mehr Bytes schaden nicht, solange Sie 128 Zeichen nicht \u00fcberschreiten.<\/p>\n\n\n\n
\/\/ Beispiel-Ausgabe in der Node-REPL\nimport { createVerifier, createChallenge } from '.\/pkce.js';\nconst v = createVerifier();\nconsole.log('verifier:  ', v);\nconsole.log('challenge: ', createChallenge(v));\n\n\/\/ Ausgabe (Werte sind bei jedem Lauf neu):\n\/\/ verifier:   sT9c2mQ8vH4kP1nR7xY0wZ3aB6dE5fG-jL_oN8uI2qS\n\/\/ challenge:  Yt4kV9p2Lm7xQ1nR8wZ0aB3cD6eF5gH-jK_lN9uI2q<\/code><\/pre>\n\n\n\n
Wichtig: Erzeugen Sie f\u00fcr jede Login-Anfrage einen frischen Verifier. Wiederverwendung untergr\u00e4bt den gesamten Schutz, weil ein einmal abgefangener Verifier dann mehrfach g\u00fcltig w\u00e4re. Genau deshalb speichern wir ihn gleich in der Session und nicht in einer globalen Variable.<\/p>\n\n\n\n
Schritt 6: State-Parameter gegen CSRF erzeugen<\/h2>\n\n\n\n
PKCE sch\u00fctzt den Code-Austausch, aber nicht gegen CSRF auf dem Callback selbst. Daf\u00fcr sorgt der state<\/code>-Parameter. Er ist ein zweiter zuf\u00e4lliger Wert, den Ihre App beim Authorization Request mitschickt und in der Session ablegt. Der Provider gibt ihn unver\u00e4ndert im Callback zur\u00fcck. Stimmen der zur\u00fcckgegebene und der gespeicherte Wert nicht \u00fcberein, brechen Sie ab. So verhindern Sie, dass ein Angreifer einem Opfer einen fremden Authorization Code unterschiebt.<\/p>\n\n\n\n
\/\/ state.js\nimport crypto from 'node:crypto';\n\n\/\/ 16 Zufallsbytes als hex, ausreichend gegen CSRF\nexport function createState() {\n  return crypto.randomBytes(16).toString('hex');\n}\n\n\/\/ zeitkonstanter Vergleich gegen Timing-Angriffe\nexport function safeEqual(a, b) {\n  const bufA = Buffer.from(a ?? '', 'utf8');\n  const bufB = Buffer.from(b ?? '', 'utf8');\n  if (bufA.length !== bufB.length) return false;\n  return crypto.timingSafeEqual(bufA, bufB);\n}<\/code><\/pre>\n\n\n\n
Beachten Sie crypto.timingSafeEqual<\/code>. Ein naiver Vergleich mit ===<\/code> bricht beim ersten abweichenden Zeichen ab und verr\u00e4t \u00fcber die Laufzeit Hinweise auf den korrekten Wert. Bei sicherheitsrelevanten Vergleichen ist der zeitkonstante Vergleich Pflicht. F\u00fcr eine noch st\u00e4rkere Absicherung gegen Login-CSRF k\u00f6nnen Sie zus\u00e4tzlich einen nonce<\/code> mitf\u00fchren und ihn sp\u00e4ter gegen den ID Token pr\u00fcfen, dazu mehr in Schritt 10.<\/p>\n\n\n\n
Schritt 7: Authorization Request aufbauen und weiterleiten<\/h2>\n\n\n\n
Jetzt verbinden wir die Bausteine. Die Route \/login<\/code> erzeugt Verifier, Challenge und State, speichert Verifier und State in der Session und baut die Authorization-URL mit allen Parametern zusammen. Anschlie\u00dfend leiten wir den Browser des Nutzers dorthin weiter.<\/p>\n\n\n\n
\/\/ in server.js ergaenzen\nimport { createVerifier, createChallenge } from '.\/pkce.js';\nimport { createState, safeEqual } from '.\/state.js';\n\napp.get('\/login', (req, res) => {\n  const verifier = createVerifier();\n  const challenge = createChallenge(verifier);\n  const state = createState();\n\n  \/\/ Schritt 7: temporaer in der Session ablegen\n  req.session.pkceVerifier = verifier;\n  req.session.oauthState = state;\n\n  const params = new URLSearchParams({\n    response_type: 'code',\n    client_id: process.env.OAUTH_CLIENT_ID,\n    redirect_uri: process.env.OAUTH_REDIRECT_URI,\n    scope: 'openid email profile',\n    state,\n    code_challenge: challenge,\n    code_challenge_method: 'S256'\n  });\n\n  res.redirect(`${process.env.AUTH_ENDPOINT}?${params.toString()}`);\n});<\/code><\/pre>\n\n\n\n
Drei Parameter sind nicht verhandelbar. code_challenge_method=S256<\/code> erzwingt die sichere Hash-Variante. scope=openid email profile<\/code> aktiviert OpenID Connect und liefert zus\u00e4tzlich zum Access Token einen ID Token mit Nutzerdaten. state<\/code> tr\u00e4gt unseren CSRF-Schutz. Die response_type=code<\/code> macht klar, dass wir den Authorization Code Flow wollen, nicht den entfernten Implicit Flow.<\/p>\n\n\n\n
Rufen Sie nun http:\/\/localhost:3000\/login<\/code> im Browser auf. Sie sollten zur Login-Seite des Providers umgeleitet werden. In der Adressleiste sehen Sie alle Parameter inklusive der base64url-kodierten code_challenge<\/code>. Der code_verifier<\/code> taucht hier bewusst nicht auf, er bleibt sicher in Ihrer Server-Session.<\/p>\n\n\n\n
Schritt 8: Den Callback verarbeiten und State pr\u00fcfen<\/h2>\n\n\n\n
Nach erfolgreichem Login leitet der Provider zur\u00fcck zu \/callback<\/code> und h\u00e4ngt zwei Query-Parameter an: code<\/code> und state<\/code>. Unsere erste Aufgabe ist die Validierung. Wir pr\u00fcfen, ob ein Fehler zur\u00fcckkam, ob der State \u00fcbereinstimmt und ob \u00fcberhaupt ein Code vorhanden ist. Erst danach geht es zum Token-Austausch.<\/p>\n\n\n\n
app.get('\/callback', async (req, res) => {\n  const { code, state, error } = req.query;\n\n  \/\/ Schritt 8a: Provider-Fehler abfangen\n  if (error) {\n    return res.status(400).send(`OAuth-Fehler: ${error}`);\n  }\n\n  \/\/ Schritt 8b: State gegen CSRF pruefen (zeitkonstant)\n  if (!state || !safeEqual(state, req.session.oauthState)) {\n    return res.status(403).send('Ungueltiger state-Parameter');\n  }\n\n  \/\/ Schritt 8c: Code muss vorhanden sein\n  if (!code) {\n    return res.status(400).send('Kein Authorization Code erhalten');\n  }\n\n  const verifier = req.session.pkceVerifier;\n  \/\/ ... weiter in Schritt 9\n});<\/code><\/pre>\n\n\n\n
Diese drei Pr\u00fcfungen sind keine Formalit\u00e4t. Fehlt die State-Pr\u00fcfung, ist Ihre App anf\u00e4llig f\u00fcr Login-CSRF, bei dem ein Angreifer das Opfer in ein fremdes Konto einloggt. Fehlt die Fehlerbehandlung, sieht der Nutzer bei einer abgelehnten Zustimmung nur eine kaputte Seite statt einer klaren Meldung. Nach erfolgreicher Pr\u00fcfung holen wir den Verifier aus der Session, denn ihn brauchen wir gleich f\u00fcr den Beweis gegen\u00fcber dem Token Endpoint.<\/p>\n\n\n\n
Schritt 9: Authorization Code gegen Tokens tauschen<\/h2>\n\n\n\n
Der entscheidende Server-zu-Server-Aufruf. Wir senden eine POST-Anfrage an den Token Endpoint mit dem Authorization Code, dem urspr\u00fcnglichen code_verifier<\/code>, der Client-ID, dem Client-Secret und der Redirect URI. Der Provider hasht den Verifier, vergleicht ihn mit der gespeicherten Challenge und liefert bei Erfolg ein JSON mit den Tokens. Node.js 24 bringt fetch<\/code> nativ mit, ein Extra-Paket ist nicht n\u00f6tig.<\/p>\n\n\n\n
  \/\/ Fortsetzung von \/callback (Schritt 9)\n  const body = new URLSearchParams({\n    grant_type: 'authorization_code',\n    code,\n    redirect_uri: process.env.OAUTH_REDIRECT_URI,\n    client_id: process.env.OAUTH_CLIENT_ID,\n    client_secret: process.env.OAUTH_CLIENT_SECRET,\n    code_verifier: verifier            \/\/ der PKCE-Beweis\n  });\n\n  const tokenRes = await fetch(process.env.TOKEN_ENDPOINT, {\n    method: 'POST',\n    headers: { 'Content-Type': 'application\/x-www-form-urlencoded' },\n    body\n  });\n\n  if (!tokenRes.ok) {\n    const detail = await tokenRes.text();\n    return res.status(502).send(`Token-Austausch fehlgeschlagen: ${detail}`);\n  }\n\n  const tokens = await tokenRes.json();\n  \/\/ tokens: { access_token, id_token, refresh_token?, expires_in, token_type }\n\n  \/\/ Session aufraeumen: Verifier und State nicht laenger brauchen\n  delete req.session.pkceVerifier;\n  delete req.session.oauthState;<\/code><\/pre>\n\n\n\n
Eine erfolgreiche Antwort sieht so aus. Der expires_in<\/code>-Wert gibt die G\u00fcltigkeit des Access Tokens in Sekunden an, bei Google typischerweise 3600 (eine Stunde). Den refresh_token<\/code> liefert Google nur, wenn Sie zus\u00e4tzlich access_type=offline<\/code> anfordern, ein Detail, das viele Tutorials verschweigen.<\/p>\n\n\n\n
{\n  \"access_token\": \"ya29.a0Af...\",\n  \"expires_in\": 3600,\n  \"scope\": \"openid https:\/\/www.googleapis.com\/auth\/userinfo.email ...\",\n  \"token_type\": \"Bearer\",\n  \"id_token\": \"eyJhbGciOiJSUzI1NiIsImtpZCI6Ij...\"\n}<\/code><\/pre>\n\n\n\n
Wir l\u00f6schen Verifier und State nach dem Austausch sofort aus der Session. Sie sind Einmal-Werte und haben danach nichts mehr verloren. Wer sie liegen l\u00e4sst, vergr\u00f6\u00dfert die Angriffsfl\u00e4che ohne jeden Nutzen.<\/p>\n\n\n\n
Schritt 10: ID Token validieren und Nutzer einloggen<\/h2>\n\n\n\n
Der ID Token ist ein JWT nach OpenID Connect Core 1.0. Er enth\u00e4lt Claims \u00fcber den Nutzer, etwa sub<\/code> (eindeutige ID), email<\/code> und name<\/code>. Bevor Sie ihm vertrauen, m\u00fcssen Sie ihn validieren: Signatur, Aussteller (iss<\/code>), Zielgruppe (aud<\/code>) und Ablaufzeit (exp<\/code>). In Produktion pr\u00fcfen Sie die Signatur gegen die \u00f6ffentlichen Schl\u00fcssel des Providers (JWKS). F\u00fcr die Validierung lohnt sich eine gepr\u00fcfte Bibliothek, denn selbstgebaute JWT-Parser sind eine klassische Fehlerquelle.<\/p>\n\n\n\n
  \/\/ Schritt 10: ID Token dekodieren (Demo: Payload lesen)\n  \/\/ In Produktion: Signatur per JWKS pruefen, siehe openid-client unten\n  function decodeJwtPayload(jwt) {\n    const payload = jwt.split('.')[1];\n    const json = Buffer.from(payload, 'base64url').toString('utf8');\n    return JSON.parse(json);\n  }\n\n  const claims = decodeJwtPayload(tokens.id_token);\n\n  \/\/ Mindestpruefungen\n  if (claims.aud !== process.env.OAUTH_CLIENT_ID) {\n    return res.status(401).send('Token-aud passt nicht');\n  }\n  if (claims.exp * 1000 < Date.now()) {\n    return res.status(401).send('Token abgelaufen');\n  }\n\n  \/\/ Nutzer in der Session als angemeldet markieren\n  req.session.user = {\n    id: claims.sub,\n    email: claims.email,\n    name: claims.name\n  };\n  req.session.accessToken = tokens.access_token;\n\n  res.redirect('\/profil');\n});<\/code><\/pre>\n\n\n\n
Der hier gezeigte decodeJwtPayload<\/code> liest nur die Payload und pr\u00fcft aud<\/code> und exp<\/code>. Das gen\u00fcgt f\u00fcr ein Tutorial, nicht aber f\u00fcr Produktion. Ohne Signaturpr\u00fcfung k\u00f6nnte ein Angreifer mit einem selbst gebastelten Token vorbeikommen. Deshalb zeigen wir weiter unten die korrekte Variante mit openid-client<\/code>, die JWKS-Abruf und Signaturpr\u00fcfung automatisch erledigt.<\/p>\n\n\n\n
Token-Typ<\/th>Zweck<\/th>Lebensdauer (typisch)<\/th>Wer pr\u00fcft<\/th><\/tr><\/thead>
Access Token<\/td>Zugriff auf gesch\u00fctzte APIs<\/td>5 bis 60 Minuten<\/td>Resource Server<\/td><\/tr>
ID Token<\/td>Identit\u00e4t des Nutzers belegen<\/td>10 bis 60 Minuten<\/td>Ihre Client-App<\/td><\/tr>
Refresh Token<\/td>neues Access Token holen<\/td>Tage bis Monate<\/td>Authorization Server<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Schritt 11: Gesch\u00fctzte Routen mit Access Token<\/h2>\n\n\n\n
Jetzt nutzen wir die Anmeldung. Eine kleine Middleware pr\u00fcft, ob ein Nutzer in der Session steht, und sch\u00fctzt damit beliebige Routen. Die Profilseite zeigt die Nutzerdaten und ruft beispielhaft eine gesch\u00fctzte API des Providers mit dem Access Token im Authorization: Bearer<\/code>-Header auf.<\/p>\n\n\n\n
\/\/ Auth-Middleware\nfunction requireLogin(req, res, next) {\n  if (!req.session.user) {\n    return res.redirect('\/login');\n  }\n  next();\n}\n\napp.get('\/profil', requireLogin, async (req, res) => {\n  \/\/ Access Token gegen die UserInfo-API verwenden\n  const userInfo = await fetch(\n    'https:\/\/openidconnect.googleapis.com\/v1\/userinfo',\n    { headers: { Authorization: `Bearer ${req.session.accessToken}` } }\n  ).then(r => r.json());\n\n  res.send(\n    `<h1>Hallo ${req.session.user.name}<\/h1>` +\n    `<p>E-Mail: ${req.session.user.email}<\/p>` +\n    `<p>Verifiziert: ${userInfo.email_verified}<\/p>` +\n    `<a href=\"\/logout\">Abmelden<\/a>`\n  );\n});<\/code><\/pre>\n\n\n\n
Der Bearer-Token geh\u00f6rt in den HTTP-Header, niemals in die URL. OAuth 2.1 verbietet Access Tokens im Query-String ausdr\u00fccklich, weil sie sonst in Server-Logs, Proxy-Caches und der Browser-History landen. Halten Sie den Access Token au\u00dferdem server-seitig in der Session, nicht im Local Storage des Browsers, wo ihn jedes XSS-Skript auslesen k\u00f6nnte.<\/p>\n\n\n\n
Schritt 12: Logout und Refresh Token nutzen<\/h2>\n\n\n\n
Zum Abschluss zwei Bausteine, die in keiner echten App fehlen d\u00fcrfen. Der Logout zerst\u00f6rt die Session vollst\u00e4ndig. Der Refresh holt ein neues Access Token, sobald das alte abl\u00e4uft, ohne den Nutzer erneut zum Login zu zwingen. Letzteres funktioniert nur, wenn Sie beim ersten Request access_type=offline<\/code> angefordert haben und einen Refresh Token erhielten.<\/p>\n\n\n\n
\/\/ Schritt 12a: Logout\napp.get('\/logout', (req, res) => {\n  req.session.destroy(() => {\n    res.clearCookie('connect.sid');\n    res.redirect('\/');\n  });\n});\n\n\/\/ Schritt 12b: Access Token per Refresh Token erneuern\nasync function refreshAccessToken(refreshToken) {\n  const body = new URLSearchParams({\n    grant_type: 'refresh_token',\n    refresh_token: refreshToken,\n    client_id: process.env.OAUTH_CLIENT_ID,\n    client_secret: process.env.OAUTH_CLIENT_SECRET\n  });\n  const res = await fetch(process.env.TOKEN_ENDPOINT, {\n    method: 'POST',\n    headers: { 'Content-Type': 'application\/x-www-form-urlencoded' },\n    body\n  });\n  if (!res.ok) throw new Error('Refresh fehlgeschlagen');\n  return res.json(); \/\/ { access_token, expires_in, ... }\n}<\/code><\/pre>\n\n\n\n
Beim req.session.destroy<\/code> l\u00f6schen wir zus\u00e4tzlich das Cookie \u00fcber res.clearCookie<\/code>. Vergessen Sie das, bleibt eine leere, aber g\u00fcltige Session-H\u00fclle im Browser zur\u00fcck. OAuth 2.1 empfiehlt zudem Refresh Token Rotation: Bei jedem Refresh gibt der Provider einen neuen Refresh Token aus und entwertet den alten. Erkennt er einen wiederverwendeten alten Token, widerruft er die gesamte Token-Familie. Das begrenzt den Schaden, falls ein Refresh Token doch einmal abhandenkommt.<\/p>\n\n\n\n
Die kompakte Variante mit openid-client 6.8.4<\/h2>\n\n\n\n
Den manuellen Flow haben wir gebaut, um jeden Schritt zu verstehen. In echten Projekten greifen Sie zu einer gepr\u00fcften Bibliothek. openid-client<\/code> ist die meistgenutzte OIDC-Bibliothek f\u00fcr Node.js, deckt PKCE, State, Nonce und vor allem die korrekte ID-Token-Validierung per JWKS ab und reduziert den Code drastisch. Die folgende Variante ersetzt die Schritte 5 bis 10.<\/p>\n\n\n\n
npm install openid-client@6.8.4<\/code><\/pre>\n\n\n\n
\/\/ oidc.js mit openid-client 6.x\nimport * as client from 'openid-client';\n\n\/\/ Discovery laedt alle Endpunkte und JWKS automatisch\nconst config = await client.discovery(\n  new URL('https:\/\/accounts.google.com'),\n  process.env.OAUTH_CLIENT_ID,\n  process.env.OAUTH_CLIENT_SECRET\n);\n\nexport async function buildAuthUrl(session) {\n  const verifier = client.randomPKCECodeVerifier();\n  const challenge = await client.calculatePKCECodeChallenge(verifier);\n  session.pkceVerifier = verifier;\n  session.oauthState = client.randomState();\n  return client.buildAuthorizationUrl(config, {\n    redirect_uri: process.env.OAUTH_REDIRECT_URI,\n    scope: 'openid email profile',\n    code_challenge: challenge,\n    code_challenge_method: 'S256',\n    state: session.oauthState\n  });\n}\n\nexport async function handleCallback(currentUrl, session) {\n  \/\/ prueft State, tauscht Code, validiert ID Token per JWKS\n  const tokens = await client.authorizationCodeGrant(config, currentUrl, {\n    pkceCodeVerifier: session.pkceVerifier,\n    expectedState: session.oauthState\n  });\n  return tokens.claims(); \/\/ validierte ID-Token-Claims\n}<\/code><\/pre>\n\n\n\n
Der Gewinn ist nicht nur weniger Code. authorizationCodeGrant<\/code> pr\u00fcft die ID-Token-Signatur gegen die per Discovery geladenen \u00f6ffentlichen Schl\u00fcssel, validiert iss<\/code>, aud<\/code>, exp<\/code> und nonce<\/code> automatisch und sch\u00fctzt vor subtilen Fehlern, die in handgeschriebenem Code leicht passieren. F\u00fcr Produktion ist die Bibliotheksvariante klar die bessere Wahl. Die API von openid-client<\/code> hat sich mit Version 6 deutlich ver\u00e4ndert, pr\u00fcfen Sie deshalb immer die aktuelle Dokumentation auf GitHub.<\/p>\n\n\n\n
6 h\u00e4ufige Fehler bei OAuth in Node.js<\/h2>\n\n\n\n
Redirect URI stimmt nicht exakt \u00fcberein<\/h3>\n\n\n\n
Der mit Abstand h\u00e4ufigste Fehler. OAuth 2.1 verlangt einen exakten String-Vergleich der Redirect URI. http:\/\/localhost:3000\/callback<\/code> und http:\/\/localhost:3000\/callback\/<\/code> mit Schr\u00e4gstrich am Ende sind zwei verschiedene URIs. Auch 127.0.0.1<\/code> statt localhost<\/code> oder ein anderer Port f\u00fchren zum Fehler redirect_uri_mismatch<\/code>. Tragen Sie beim Provider exakt die URI ein, die Ihre App sendet.<\/p>\n\n\n\n
code_verifier geht zwischen Requests verloren<\/h3>\n\n\n\n
Login-Request und Callback sind zwei getrennte HTTP-Anfragen. Speichern Sie den Verifier in einer globalen Variable statt in der Session, geht er bei parallelen Logins durcheinander oder fehlt ganz. Die Folge ist der Token-Fehler invalid_grant<\/code>. Der Verifier geh\u00f6rt zwingend in die server-seitige Session, gebunden an das Session-Cookie des jeweiligen Nutzers.<\/p>\n\n\n\n
Weitere vier Stolperfallen in K\u00fcrze: Ein SameSite=Strict<\/code>-Cookie unterdr\u00fcckt die Session beim Callback, nutzen Sie lax<\/code>. Ein fehlendes access_type=offline<\/code> bei Google liefert keinen Refresh Token. Der Authorization Code ist nur einmal einl\u00f6sbar, ein zweiter Versuch (etwa durch Reload des Callbacks) scheitert mit invalid_grant<\/code>. Und wer dem ID Token ohne Signaturpr\u00fcfung vertraut, \u00f6ffnet die T\u00fcr f\u00fcr gef\u00e4lschte Tokens.<\/p>\n\n\n\n
Troubleshooting: 8 typische Fehlermeldungen<\/h2>\n\n\n\n
Diese Tabelle ordnet die h\u00e4ufigsten Fehlermeldungen ihren Ursachen und L\u00f6sungen zu. Sie deckt die Meldungen ab, die beim Aufbau eines OAuth-PKCE-Flows in Node.js am h\u00e4ufigsten auftreten.<\/p>\n\n\n\n
Fehlermeldung<\/th>Ursache<\/th>L\u00f6sung<\/th><\/tr><\/thead>
redirect_uri_mismatch<\/td>URI weicht vom Eintrag beim Provider ab<\/td>exakt gleiche URI eintragen, kein Slash, gleicher Port<\/td><\/tr>
invalid_grant<\/td>Code abgelaufen, schon benutzt oder Verifier fehlt<\/td>frischen Login starten, Verifier aus Session pr\u00fcfen<\/td><\/tr>
invalid_client<\/td>falsche Client-ID oder falsches Secret<\/td>.env-Werte und Provider-Eintrag abgleichen<\/td><\/tr>
code_challenge required<\/td>Provider erzwingt PKCE, App sendet keine Challenge<\/td>code_challenge und method=S256 erg\u00e4nzen<\/td><\/tr>
invalid state<\/td>State fehlt oder Session ging verloren<\/td>SameSite=lax setzen, Session-Store pr\u00fcfen<\/td><\/tr>
access_denied<\/td>Nutzer hat Zustimmung abgelehnt<\/td>Fehler abfangen, Nutzer freundlich informieren<\/td><\/tr>
unauthorized_client<\/td>Grant-Typ f\u00fcr diesen Client nicht erlaubt<\/td>in Provider-Konsole Authorization Code aktivieren<\/td><\/tr>
Cannot read properties of undefined<\/td>–env-file fehlt, Variablen sind leer<\/td>node –env-file=.env server.js starten<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Ein praktischer Debugging-Tipp: Loggen Sie bei einem fehlgeschlagenen Token-Austausch immer den vollst\u00e4ndigen Antworttext des Providers, nicht nur den HTTP-Status. Die Provider liefern im JSON-Feld error_description<\/code> oft eine sehr pr\u00e4zise Ursache, die das halbe R\u00e4tsel l\u00f6st. In Produktion entfernen Sie diese ausf\u00fchrlichen Logs wieder, damit keine sensiblen Details in den Protokollen landen.<\/p>\n\n\n\n
Fortgeschrittene Tipps f\u00fcr den Produktivbetrieb<\/h2>\n\n\n\n
Der Tutorial-Code l\u00e4uft, doch f\u00fcr Produktion brauchen Sie mehr. Setzen Sie cookie.secure: true<\/code> und betreiben Sie die App ausschlie\u00dflich \u00fcber HTTPS, etwa hinter einem Reverse Proxy mit g\u00fcltigem Zertifikat. Hinter einem Proxy m\u00fcssen Sie zus\u00e4tzlich app.set('trust proxy', 1)<\/code> setzen, sonst h\u00e4lt Express die Verbindung f\u00e4lschlich f\u00fcr unsicher und sendet das Secure-Cookie nicht.<\/p>\n\n\n\n
Der Standard-Session-Store von express-session<\/code> h\u00e4lt Sessions nur im Arbeitsspeicher und ist f\u00fcr Produktion ungeeignet, weil er bei jedem Neustart alle Logins verliert und nicht \u00fcber mehrere Instanzen skaliert. Nutzen Sie einen externen Store wie Redis. Begrenzen Sie die angeforderten Scopes auf das Minimum: Wer nur die E-Mail braucht, fordert nicht den vollen Profilzugriff an. Das Prinzip der minimalen Rechte gilt auch bei OAuth.<\/p>\n\n\n\n
Aktivieren Sie Refresh Token Rotation, wenn Ihr Provider sie unterst\u00fctzt, und speichern Sie Refresh Tokens verschl\u00fcsselt. Erw\u00e4gen Sie f\u00fcr besonders sensible Anwendungen DPoP (Demonstrating Proof of Possession), das Tokens an einen kryptografischen Schl\u00fcssel des Clients bindet und so gestohlene Bearer Tokens wertlos macht. F\u00fcr Server-zu-Server-Szenarien ohne Nutzer nutzen Sie den Client Credentials Grant statt des Authorization Code Flows. Wer Signaturen und Schl\u00fcssel in Node.js tiefer verstehen will, findet in unserem Leitfaden zu ECDSA in Node.js die passende Erg\u00e4nzung.<\/p>\n\n\n\n
OAuth-Flows im Vergleich: Welcher Grant f\u00fcr welchen Fall<\/h2>\n\n\n\n
OAuth kennt mehrere Grant-Typen, doch nach der Bereinigung durch OAuth 2.1 bleiben nur wenige \u00fcbrig, die Sie 2026 noch einsetzen sollten. Die Wahl h\u00e4ngt vom Anwendungsfall ab: Web-App mit Backend, native Mobile-App, Single-Page-App oder reine Maschine-zu-Maschine-Kommunikation. Wer den falschen Flow w\u00e4hlt, baut sich entweder eine Sicherheitsl\u00fccke oder unn\u00f6tige Komplexit\u00e4t ein.<\/p>\n\n\n\n
F\u00fcr klassische Server-gerenderte Web-Apps, wie die in diesem Tutorial, ist der Authorization Code Flow mit PKCE die richtige Wahl. F\u00fcr Single-Page-Apps gilt dasselbe, erg\u00e4nzt um die Empfehlung, Tokens \u00fcber ein leichtes Backend (Backend for Frontend, BFF) zu verwalten statt im Browser. Native Apps nutzen ebenfalls Authorization Code mit PKCE, oft kombiniert mit dem System-Browser statt eines eingebetteten Webviews. F\u00fcr Skript-zu-API-Aufrufe ohne menschlichen Nutzer gibt es den Client Credentials Grant, der ganz ohne Browser-Umweg auskommt.<\/p>\n\n\n\n
Grant-Typ<\/th>Anwendungsfall<\/th>PKCE<\/th>OAuth-2.1-Status<\/th><\/tr><\/thead>
Authorization Code + PKCE<\/td>Web-App mit Backend<\/td>Pflicht<\/td>empfohlen<\/td><\/tr>
Authorization Code + PKCE<\/td>SPA und Mobile-App<\/td>Pflicht<\/td>empfohlen<\/td><\/tr>
Client Credentials<\/td>Maschine zu Maschine<\/td>nicht n\u00f6tig<\/td>erlaubt<\/td><\/tr>
Device Code<\/td>TV, IoT, CLI ohne Browser<\/td>optional<\/td>erlaubt<\/td><\/tr>
Implicit<\/td>fr\u00fcher: SPA<\/td>nicht m\u00f6glich<\/td>entfernt<\/td><\/tr>
Password Grant<\/td>fr\u00fcher: vertraute Apps<\/td>nicht m\u00f6glich<\/td>entfernt<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Halten Sie sich an die obere H\u00e4lfte der Tabelle. Implicit und Password Grant stehen nur noch zur Abgrenzung dort. Wer eine bestehende App von Implicit auf Authorization Code mit PKCE migriert, beseitigt damit die gr\u00f6\u00dfte strukturelle Schwachstelle \u00e4lterer OAuth-Integrationen. Der Device Code Flow ist die richtige Antwort, wenn ein Ger\u00e4t keinen Browser hat, etwa ein Smart-TV oder ein Kommandozeilen-Tool, das den Nutzer einen Code auf einem zweiten Ger\u00e4t best\u00e4tigen l\u00e4sst.<\/p>\n\n\n\n
Provider-Endpunkte f\u00fcr Google, Microsoft und GitHub<\/h2>\n\n\n\n
Der Code in diesem Tutorial ist providerneutral. Sie tauschen nur Authorization Endpoint, Token Endpoint und die Scopes, der Rest bleibt gleich. F\u00fcr die drei in der DACH-Region am h\u00e4ufigsten genutzten Provider sehen die Endpunkte wie folgt aus. Bei OpenID-Connect-Providern k\u00f6nnen Sie diese Werte auch automatisch \u00fcber das Discovery-Dokument unter \/.well-known\/openid-configuration<\/code> laden, statt sie fest zu hinterlegen.<\/p>\n\n\n\n
Provider<\/th>Authorization Endpoint<\/th>OIDC-Discovery<\/th>PKCE<\/th><\/tr><\/thead>
Google<\/td>accounts.google.com\/o\/oauth2\/v2\/auth<\/td>ja<\/td>unterst\u00fctzt<\/td><\/tr>
Microsoft Entra ID<\/td>login.microsoftonline.com\/…\/authorize<\/td>ja<\/td>unterst\u00fctzt<\/td><\/tr>
GitHub<\/td>github.com\/login\/oauth\/authorize<\/td>kein OIDC<\/td>unterst\u00fctzt<\/td><\/tr>
Okta<\/td>{domain}\/oauth2\/v1\/authorize<\/td>ja<\/td>unterst\u00fctzt<\/td><\/tr>
Auth0<\/td>{domain}\/authorize<\/td>ja<\/td>unterst\u00fctzt<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Ein wichtiger Unterschied: GitHub spricht reines OAuth 2.0 ohne OpenID Connect und liefert deshalb keinen ID Token. Wenn Sie GitHub als Login nutzen, holen Sie die Nutzerdaten stattdessen \u00fcber die GitHub-API mit dem Access Token. Google, Microsoft Entra ID, Okta und Auth0 sprechen vollst\u00e4ndiges OpenID Connect und liefern einen ID Token mit den Identity-Claims. F\u00fcr diese Provider lohnt sich openid-client<\/code> mit Discovery besonders, weil Sie dann nur die Issuer-URL kennen m\u00fcssen.<\/p>\n\n\n\n
Bei Microsoft Entra ID (vormals Azure AD) steckt in der Endpunkt-URL die Tenant-ID oder der Platzhalter common<\/code> f\u00fcr Multi-Tenant-Apps. Achten Sie darauf, den richtigen Tenant zu w\u00e4hlen, sonst lehnt der Token Endpoint die Anfrage ab. Bei selbst gehosteten Providern wie Keycloak setzt sich die Issuer-URL aus Host und Realm zusammen, der restliche Flow bleibt identisch zu unserem Google-Beispiel.<\/p>\n\n\n\n
Das vollst\u00e4ndige Projekt im \u00dcberblick<\/h2>\n\n\n\n
So sieht die Verzeichnisstruktur des fertigen Projekts aus. Drei Hilfsmodule, eine zentrale server.js<\/code> und die Konfiguration in .env<\/code>. Mit dieser Struktur l\u00e4sst sich der Flow leicht testen und sp\u00e4ter um openid-client<\/code> erweitern.<\/p>\n\n\n\n
oauth-pkce-node\/\n\u251c\u2500\u2500 .env                # Geheimnisse, niemals committen\n\u251c\u2500\u2500 .gitignore          # enthaelt .env und node_modules\n\u251c\u2500\u2500 package.json        # \"type\": \"module\"\n\u251c\u2500\u2500 server.js           # Express-App, Routen \/login \/callback \/profil \/logout\n\u251c\u2500\u2500 pkce.js             # createVerifier, createChallenge\n\u251c\u2500\u2500 state.js            # createState, safeEqual\n\u2514\u2500\u2500 oidc.js             # optionale openid-client-Variante\n\n# Starten:\nnode --env-file=.env server.js\n# Browser: http:\/\/localhost:3000\/login<\/code><\/pre>\n\n\n\n
Wenn Sie \/login<\/code> aufrufen, den Provider-Login durchlaufen und auf \/profil<\/code> landen, funktioniert der gesamte Flow. Sie haben damit einen vollst\u00e4ndigen, PKCE-gesicherten OAuth-Login gebaut, der den Anforderungen von OAuth 2.1 entspricht. F\u00fcr den Produktiveinsatz ersetzen Sie die manuelle ID-Token-Pr\u00fcfung durch openid-client<\/code>, schalten Secure-Cookies und HTTPS ein und hinterlegen einen Redis-Session-Store.<\/p>\n\n\n\n
Sicherheits-Checkliste vor dem Go-Live<\/h2>\n\n\n\n
Bevor Ihre OAuth-Integration in Produktion geht, sollten Sie die folgenden Punkte abhaken. Jeder einzelne hat in der Praxis schon zu kompromittierten Logins gef\u00fchrt. Die Liste fasst zusammen, was \u00fcber das reine Funktionieren des Flows hinaus z\u00e4hlt.<\/p>\n\n\n\n