OAuth entwickeln und prüfen
Öffnen Sie das öffentliche Beispiel und vergleichen Sie Anfrage und Rückgabe, bevor Sie eigene Werte einsetzen.
Rohe Werte eingeben. Die registrierte Redirect-URI bleibt als Wert unverändert.
Alle Eingaben werden in diesem Tab verarbeitet, nicht versendet oder gespeichert.
response_type=code · Authorization-Code-Ablauf
Verifier für die Token-Anfrage behalten. Nur die Challenge kommt in die URL; Berichte enthalten keinen Verifier.
Zusatzparameter: je eine rohe key=value-Zeile. Nicht vorkodieren oder reservierte Felder wiederholen.
Werte eingeben oder Beispiel laden.
Ein anderer Port oder ein zusätzliches Zeichen am Ende der Rücksprungadresse kann einen Login verhindern. Mit diesem Werkzeug sehen Sie die OAuth-Autorisierungs-URL neben den dekodierten Parametern. So lässt sich prüfen, ob die tatsächlichen Werte noch zu Ihrer Client-Konfiguration passen.
Für die Untersuchung einer bereits erhaltenen Rückgabe wechseln Sie zur Callback-Ansicht. Tragen Sie den damals gespeicherten state separat ein. Auch mehrfach vorkommende Namen bleiben als einzelne Zeilen erhalten. Eine lesbare Rückgabe ist dabei kein Nachweis einer gültigen Anmeldung.
Die OAuth-Autorisierungs-URL enthält bei aktiviertem PKCE nur die abgeleitete S256-Challenge und die Methode. Der Verifier bleibt im Eingabefeld und lässt sich für den späteren Token-Aufruf getrennt kopieren. Auch der Bericht enthält ihn nicht.
Steht state sowohl im Query als auch im Fragment, zeigt die Tabelle beide Quellen. Selbst zwei identische Werte gelten als mehrdeutig. Damit verschwindet ein unerwarteter zweiter Wert nicht hinter einem zufällig passenden ersten Treffer.
Übernehmen Sie Schema, Port, Pfad, abschließenden Schrägstrich und vorhandenen Query des Weiterleitungs-URI. Kodieren Sie nicht vorher die gesamte Adresse. Zusätzliche Werte werden als rohe key=value-Zeilen eingegeben; ein & innerhalb des Werts gehört zum Wert.
Die Generierung verwendet jeweils 32 unabhängige Zufallsbytes für state und Verifier. Enthält scope das einzelne Element openid, wird auch nonce ersetzt. Prüfen Sie die Vorschau und bewahren Sie den Verifier für dieselbe Transaktion auf. Eine Scope-Änderung erzeugt keine neuen Werte.
Automatisch wird nach 350 ms ohne weitere Änderung gerechnet. Bei ausgeschalteter Automatik nutzen Sie die Ausführungsschaltfläche oder Ctrl/Cmd+Enter. Veraltete Ergebnisse sind nicht exportierbar. Beide Ansichten behalten ihre Eingaben; der erwartete Callback-state ist ein eigenes Feld.
Der gesamte redirect_uri bleibt ein einzelner Parameterwert der Autorisierungsanfrage. Vorhandene Endpoint-Parameter werden streng dekodiert und zusammen mit den Formularwerten neu kodiert. Ein rohes Plus im Zusatzwert wird zu %2B, Leerzeichen folgen der Formularkodierung.
Akzeptiert werden Verifier mit 43–128 erlaubten Zeichen. Leerraum wird nicht entfernt und Base64 nicht vorab dekodiert. Beim Ausschalten von PKCE verschwinden Challenge und Methode aus der URL, während der eingegebene Verifier erhalten bleibt.
Vollständige URLs, ?query, #fragment und reine Query-Strings werden einmal dekodiert. %252F wird also zu %2F und nicht zu einem Schrägstrich. Leere Namen, leere Werte und Duplikate bleiben in ihrer Reihenfolge sichtbar.
Fehlender, leerer, mehrfacher, ungeprüfter, passender und abweichender state haben eigene Meldungen. Gemischte code/error-Antworten werden gekennzeichnet. Bei langen Tabellen lassen sich je 50 weitere Zeilen anzeigen; der Export umfasst immer sämtliche Parameter.
Ein anderes Schema, ein Port, Pfad oder abschließender Schrägstrich kann auf einen anderen Empfänger verweisen. Registrieren Sie die tatsächlich verwendete Adresse beim Anbieter. Das Werkzeug bewahrt Ihre Zeichenfolge als Parameterwert, kann jedoch die Registrierung des Clients nicht einsehen.
State kommt als Callback-Parameter zurück und wird mit dem ursprünglichen Transaktionswert verglichen. Nonce ist an ein ID Token gebunden und wird nach dessen Validierung geprüft. Ein nonce-Feld im eingefügten Callback ersetzt diese Prüfung nicht.
Das Secret authentifiziert den Client am Token-Endpoint. PKCE bindet zusätzlich den Code an den ursprünglichen Verifier. Aktuelle Sicherheitsempfehlungen sehen PKCE auch für vertrauliche Clients vor. Prüfen Sie, ob Ihr Anbieter S256 unterstützt.
Ja. Sie ist eine öffentliche Kennung. client_secret und code_verifier haben andere Aufgaben und gehören nicht in den Autorisierungsquery. Diese Namen werden blockiert; den Verifier kopieren Sie mit einer eigenen Schaltfläche.
OAuth regelt den Zugriff auf Ressourcen. OpenID Connect ergänzt die Benutzeranmeldung und ein ID Token. Verwenden Sie openid im Scope und bei Bedarf nonce. Die Prüfung des zurückgegebenen ID Tokens bleibt Aufgabe Ihrer Anwendung.
Eine unerwartete Berechnung entdeckt?
Prüfen Sie die OAuth-Autorisierungs-URL gegen die Registrierung beim Anbieter. Vergleichen Sie anschließend den eingefügten Callback mit dem für genau diese Transaktion gespeicherten state.