Metadaten des Identity Providers
Discovery-JSON einfügen. Für eine zweite Konfiguration den Vergleich einschalten.
Die Verarbeitung bleibt in diesem Tab. Keine Übertragung, Speicherung oder Abfrage externer Daten.
Dokument einfügen oder Beispiel laden.
Gilt unverändert für beide Dokumente. Leer lassen, um den Abgleich mit einem Erwartungswert auszulassen.
Dokument einfügen oder Beispiel laden.
Geprüft werden Metadaten, nicht die Serveridentität, Erreichbarkeit oder Tokensignatur.
Eine Aussteller-URL kann im Browser erreichbar sein und trotzdem nicht zum konfigurierten Issuer passen. Wer eine OIDC-Konfiguration prüfen möchte, braucht daher den ursprünglichen Wert neben einer konkreten Diagnose. Hier lassen sich Pflichtfelder und Erwartungswerte auseinanderhalten, bevor die Fehlersuche beim Anmeldeablauf weitergeht.
Das OpenID-Konfigurationsdokument beschreibt die vom Anbieter veröffentlichten Fähigkeiten. Beim Wechsel eines Reverse Proxys oder einer Mandantenadresse lohnt sich zusätzlich der Vergleich mit dem vorherigen Stand. OIDC-Discovery liefert dafür die Metadaten, aber keinen Beleg für eine funktionierende Anmeldung.
Eine OIDC-Konfiguration prüfen heißt hier: Werte nach Aussteller, Endpunkten, Algorithmen und Fähigkeiten betrachten. Fehlende Pflichtfelder bleiben im Bericht sichtbar. Erweiterungen außerhalb des Prüfumfangs werden als ungeprüft bezeichnet. Über die Fundstelle gelangen Sie direkt zum betreffenden Feld im Original.
A enthält den alten Stand, B den vorgesehenen neuen. Jeder Stand erhält einen eigenen Feldbericht. Der Vergleich zeigt zusätzlich Ergänzungen, Löschungen und Änderungen mit JSON Pointer. So lassen sich Änderungen an Schlüsseladressen und Signaturlisten getrennt von unveränderten Angaben beurteilen.
Der optionale Erwartungswert gilt für beide Dokumente. Großschreibung, Port und abschließender Schrägstrich bleiben relevant. Bei absichtlich unterschiedlichen Umgebungen lassen Sie ihn leer und lesen die Unterschiede.
Automatisch wird nach 350 ms Eingabepause geprüft. Bei ausgeschalteter Automatik starten die Schaltfläche oder Strg/Cmd + Enter die Prüfung. Jede Änderung sperrt sofort den Export des alten Ergebnisses.
Dokument A und B zeigen ihre jeweiligen Feldbefunde, Unterschiede die Richtung A nach B. Fundstellen führen zum Eingabefeld. Die Anzeige wächst um jeweils 50 Einträge; der Export enthält trotzdem den vollständigen Bericht.
Geprüft werden issuer, Autorisierungsendpunkt, jwks_uri, Antworttypen, Subject-Typen und ID-Token-Signaturen. Der Token-Endpunkt darf nur fehlen, wenn Antworttypen und ausdrücklich angegebene Grants ausschließlich den Implicit Flow erkennen lassen. Fehlende optionale Angaben werden nicht ergänzt.
Protokollendpunkte benötigen absolute HTTPS-Adressen ohne Zugangsdaten oder Fragment. Der Issuer darf zusätzlich keine Query enthalten. Die Gleichheitsprüfung normalisiert keine URLs. Ein Endpunkt auf einem anderen Host ist erlaubt und allein kein Konfigurationsfehler.
RS256 ist in der ID-Token-Signaturliste erforderlich. none führt dort zu einem Hinweis, bei Signaturen zur Clientauthentifizierung dagegen zu einem Fehler. Scope-, Grant- und Fähigkeitsangaben werden als Deklarationen gelesen; unbekannte Algorithmen gelten nicht automatisch als unzulässig.
Große Ganzzahlen und lange Dezimalwerte bleiben erhalten. JSON Pointer bezeichnet auch verschachtelte Erweiterungswerte eindeutig. Objektschlüssel dürfen umgeordnet sein, Arrayelemente werden positionsweise verglichen. Fehlende Werte und null bleiben unterscheidbar.
Prüfen Sie Schema, Mandantenpfad, öffentlichen Host und abschließenden Schrägstrich. Ein Reverse Proxy kann eine interne HTTP-Adresse veröffentlichen, obwohl der Client HTTPS erwartet. Der genaue Zeichenvergleich zeigt diese Abweichung; die Erwartung bloß anzupassen beseitigt die Ursache nicht.
Bei OpenID Connect wird /.well-known/openid-configuration an den Issuer-Pfad angehängt. Maßgeblich ist die Dokumentation Ihres Providers. Beschaffen Sie das JSON über Ihren üblichen Ablauf und fügen Sie es ein; diese Seite ruft keine URL ab.
Nein. Lesen Sie jwks_uri aus den Metadaten. Pfad und Host können abweichen. Das Werkzeug zeigt die veröffentlichte Adresse, nicht den Inhalt des entfernten Schlüsselsatzes.
Beim Abruf aus einem Browser benötigt der entfernte Server passende Cross-Origin-Header. Die lokale Textanalyse dieser Seite umgeht den Abruf, prüft aber auch keine CORS-Regeln. Ein erfolgreicher Bericht sagt daher nichts über die Netzwerkberechtigungen Ihres Clients aus.
Keycloak veröffentlicht die Adresse seines öffentlichen Schlüsselsatzes als jwks_uri. Welche Schlüssel der Client bezieht, hängt von dessen Bibliothek und Konfiguration ab. Hier wird die Adresse gelesen; eine Schlüsseldatei oder Anmeldung wird nicht erzeugt.
Eine unerwartete Berechnung entdeckt?
Vor einer Umstellung die OIDC-Konfiguration prüfen und den Bericht dem geprüften Versionsstand zuordnen. So bleiben deklarierte Änderungen von noch ausstehenden Protokolltests unterscheidbar.