Zum Hauptinhalt springen
Bethemesh
Sicherheit & Datenschutz

OAuth-PKCE-Generator

Erstelle einen zufälligen code_verifier mit 43 bis 128 Zeichen und seine S256-code_challenge (RFC 7636) oder berechne die Challenge eines vorhandenen Verifiers, dazu einen zufälligen state und die Parameter für die Autorisierungsanfrage.

  • Zwischenablage

Dieses Widget einbetten

Passe die Darstellung an, prüfe die Vorschau und kopiere anschließend den Code.

Vorschau

Art des Einbettungscodes

Zu kopierender Code

Responsive und automatisch von Bethemesh in der Größe angepasst.

Leer lassen, um einen zu erzeugen, oder einen vorhandenen Verifier einfügen, um seine Challenge zu berechnen.

PKCE-Werte

Bleibt beim Client und wird beim Tausch des Codes gegen ein Token gesendet.

Base64URL des SHA-256 des Verifiers, wird in der Autorisierungsanfrage gesendet.

Zufallswert, den du bei der Rückkehr prüfst, um CSRF-Angriffe zu blockieren.

War dieses Werkzeug hilfreich?

Wie funktioniert dieses Tool?

Der OAuth-PKCE-Generator erzeugt das Paar aus code_verifier und code_challenge, das der Authorization-Code-Flow mit PKCE verlangt, sowie einen state-Parameter. Er richtet sich an Entwickler, die OAuth 2.0 oder OpenID Connect in eine SPA, eine Mobile-App oder ein Kommandozeilen-Tool einbauen, und an alle, die den Ablauf von Hand mit curl oder Postman testen.

PKCE (Proof Key for Code Exchange, RFC 7636) schützt den Autorisierungscode vor dem Abfangen. Der Client erzeugt einen geheimen code_verifier aus 43 bis 128 Zeichen der nicht reservierten Menge A–Z, a–z, 0–9, „-“, „.“, „_“ und „~“; das Tool erzeugt standardmäßig 64 Zeichen mit crypto.getRandomValues. Anschließend berechnet es code_challenge = BASE64URL(SHA-256(code_verifier)) ohne Auffüllzeichen. Mit dem Beispiel aus Anhang B der RFC ergibt der Verifier dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk die Challenge E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM.

Die Challenge wird mit code_challenge_method=S256 und einem zufälligen state in der Autorisierungsanfrage mitgeschickt; der Verifier bleibt beim Client. Beim Tausch des Codes gegen ein Token sendet der Client code_verifier an den Token-Endpunkt, und der Server berechnet den SHA-256 neu, um ihn mit der erhaltenen Challenge zu vergleichen. Wer den Code abfängt, kann ihn ohne Verifier also nicht einlösen. Das Tool zeigt die Parameter code_challenge, code_challenge_method und state, die du an die Autorisierungs-URL anhängst, und berechnet auf Wunsch die Challenge eines eingefügten Verifiers neu, damit du deine eigene Implementierung prüfen kannst.

So verwenden Sie dieses Tool

  1. Verifier erzeugen oder einfügen

    Wähle eine Länge von 43 bis 128 Zeichen (Standard 64), um einen code_verifier zu erzeugen, oder füge einen vorhandenen Verifier ein, um seine Challenge zu berechnen.

  2. Challenge und state übernehmen

    Kopiere die S256-code_challenge und den zufälligen state und achte auf die angezeigte Länge von Verifier und Challenge (43 Zeichen bei SHA-256).

  3. Autorisierungsanfrage vervollständigen

    Hänge code_challenge, code_challenge_method=S256 und state an die Autorisierungs-URL an und bewahre den Verifier auf, um ihn beim Code-Tausch zu senden.

Anwendungsfälle

Einen OAuth-Flow von Hand testen

Baue eine Autorisierungs-URL für Google, Microsoft Entra ID, Okta oder Keycloak, melde dich im Browser an und tausche den Code dann per curl mit dem erzeugten code_verifier ein.

Einen invalid_grant-Fehler debuggen

Dein Server meldet „PKCE verification failed“: Füge den Verifier deiner App ein und prüfe, ob die gesendete Challenge wirklich der Base64URL-kodierte SHA-256 ist, ohne = und ohne die Zeichen + und /.

Einen Postman- oder Insomnia-Client einrichten

Erzeuge ein Paar aus Verifier und Challenge sowie einen state, um einen HTTP-Client von Hand zu befüllen, der PKCE nicht automatisch unterstützt.

Tipps und bewährte Vorgehensweisen

  • Erzeuge für jeden Login-Versuch einen neuen Verifier und einen neuen state: Ein fest wiederverwendetes Paar hebelt PKCE aus.
  • Verwende nicht die Methode plain: RFC 7636 sieht plain nur für Clients vor, die kein SHA-256 berechnen können, und das trifft auf keinen aktuellen Browser und keine Mobile-Plattform zu.
  • Speichere den Verifier in einer SPA während der Weiterleitung in sessionStorage statt im dauerhaften Browserspeicher und lösche ihn, sobald der Code eingetauscht ist.

Häufig gestellte Fragen

Was ist PKCE bei OAuth?

PKCE (RFC 7636) ist eine Erweiterung des Authorization-Code-Flows: Beim Tausch des Codes beweist der Client, dass er die Anfrage gestartet hat. Zuerst sendet er eine aus einem Geheimnis abgeleitete code_challenge, danach das Geheimnis selbst (code_verifier). Ein abgefangener Code ist ohne dieses Geheimnis wertlos.

Wie lang muss der code_verifier sein?

Zwischen 43 und 128 Zeichen, ausschließlich aus A–Z, a–z, 0–9 und „- . _ ~“. RFC 7636 empfiehlt, ihn aus mindestens 32 zufälligen Bytes zu erzeugen, was 43 Base64URL-Zeichen ergibt. Mit 64 Zeichen hast du reichlich Spielraum.

Soll ich S256 oder plain verwenden?

S256. Bei plain ist die Challenge gleich dem Verifier, sodass jeder, der die Autorisierungsanfrage sieht, auch das Geheimnis kennt. Server mit PKCE-Unterstützung müssen S256 akzeptieren, plain gibt es nur noch für Altfälle.

Braucht man mit PKCE noch den state-Parameter?

RFC 9700 erkennt an, dass PKCE vor CSRF schützt, wenn der Server es tatsächlich durchsetzt, doch state bleibt empfohlen, um die Antwort an die Sitzung des Nutzers zu binden und Anwendungskontext zu transportieren. Viele Anbieter verlangen ihn weiterhin. Deshalb erzeugt das Tool beides.

Ist PKCE für vertrauliche Clients Pflicht?

RFC 9700 (OAuth 2.0 Security Best Current Practice, 2025) schreibt PKCE für öffentliche Clients vor und empfiehlt es für vertrauliche; der Entwurf von OAuth 2.1 macht es für jeden Client mit Authorization Code verpflichtend. In der Praxis aktivierst du es am besten überall, auch bei Server-Apps mit client_secret.

Warum wird meine code_challenge abgelehnt?

Typische Fehler sind eine Challenge in Standard-Base64 (mit +, / oder =) statt Base64URL, ein Hash über eine Hex-Darstellung des SHA-256 oder ein anderer Verifier bei Autorisierungsanfrage und Code-Tausch. Füge deinen Verifier ins Tool ein und vergleiche mit der erwarteten Challenge, die lokal ohne Netzwerkanfrage berechnet wird.

Verwandte Werkzeuge

Mit diesen Werkzeugen weitermachen

Werkzeuge, die diesem ähnlich sind oder es ergänzen.

Passt gut zu

Generator für sichere Token

Erzeuge sichere Zufallstoken von 8 bis 256 Byte in Hex, Base64 oder Base64URL, mit optionalem Präfix.

Sicherheit & DatenschutzNeuDieses Werkzeug verwenden

JWK-/JWKS-Inspektor

Analysiere einen JWK oder ein JWKS: kid, kty, alg, use, RFC-7638-Thumbprint und Warnung bei offengelegtem privatem Schlüssel.

Sicherheit & DatenschutzNeuDieses Werkzeug verwenden

JWT-Signaturprüfung

Prüfe die Signatur eines JWT mit einem HMAC-Secret oder einem öffentlichen Schlüssel als JWK, JWKS oder PEM und kontrolliere exp, nbf, iss und aud.

Sicherheit & DatenschutzDieses Werkzeug verwenden

Auch interessant