Fügen Sie Metadaten ein, keine produktiven Geheimnisse oder Tokens. Die Prüfung kontaktiert den Anbieter nicht und bestätigt weder Clientregistrierung noch erlaubte Redirects.
Läuft lokal in deinem BrowserVerwenden Sie Authorization Code mit PKCE für Browser- und Mobilclients. Die lokale Prüfung bestätigt weder Provider-Registrierung, Redirect-URI-Allowlist und Consent-Richtlinie noch das Verhalten aktiver Tokens.
Fügen Sie das JSON ein, das /.well-known/openid-configuration zurückgibt, drücken Sie OIDC-Konfiguration prüfen und lesen Sie die Befunde: Die Seite benennt die Felder, von denen ein öffentlicher Authorization-Code-Client abhängt, und trennt blockierende Probleme von Punkten zum Nachsehen. Die Felder Client-ID und Redirect-URI sind optional und machen die lokale Prüfung nur konkreter.
Die PKCE-Schaltfläche zieht 48 zufällige Bytes, hashed sie mit SHA-256 und zeigt den Code-Verifier, die S256-Challenge und einen state-Wert. Alles läuft in diesem Tab über die Web Crypto API; die eingefügten Metadaten gehen weder an VoriTools noch an den Identity Provider.
Der Inspektor liest die Felder, von denen ein Browser- oder Mobilclient abhängt: issuer, authorization_endpoint und token_endpoint müssen absolute URLs sein - HTTPS in Produktion, HTTP nur auf Loopback-Adressen - und jwks_uri muss angegeben sein, damit Tokensignaturen geprüft werden können. response_types_supported muss code enthalten und grant_types_supported muss authorization_code enthalten, damit der Authorization-Code-Ablauf möglich ist.
Das Feld mit der größten Wirkung für einen öffentlichen Client ist code_challenge_methods_supported. Ohne PKCE kann ein Autorisierungscode, der auf einem Mobilgerät oder über ein eigenes URL-Schema abgefangen wird, von der abfangenden Stelle eingelöst werden; deshalb gilt ein Angebot, das nur plain listet oder das Feld weglässt, hier als blockierend und nicht als Hinweis.
PKCE-Set erzeugen nimmt 48 zufällige Bytes aus crypto.getRandomValues, kodiert sie base64url und zeigt den 64 Zeichen langen Code-Verifier. Die S256-Challenge ist der base64url-Wert des SHA-256-Hashs dieses Verifiers - 43 Zeichen - und der state-Wert sind 24 zufällige Bytes, 32 Zeichen, zum Abgleich, wenn der Anbieter mit dem Code zurückleitet.
Verwenden Sie S256: Die Challenge reist in der Autorisierungsanfrage, der Verifier bleibt bis zur Token-Anfrage im Client, und ein dazwischen abgefangener Code lässt sich nicht einlösen. Die plain-Methode schickt den Verifier selbst in der URL; deshalb endet ein Dokument, das nur plain unterstützt, hier mit einem blockierenden Befund.
Das Dokument wird genau so gelesen, wie es eingefügt wurde. Die Seite kann nicht sagen, ob der Anbieter Ihren Client registriert hat, ob die Redirect-URI auf seiner Liste steht, welchen Consent-Bildschirm der Nutzer sieht oder ob sich die Endpunkte wie angegeben verhalten; das erfordert eine echte Autorisierungsanfrage beim Anbieter.
Ein Ergebnis ohne Befunde heißt also, dass die kopierten Metadaten für einen öffentlichen Client in sich stimmig sind - nicht, dass die Integration funktioniert. Echte Abläufe, Token-Laufzeiten und Refresh-Verhalten müssen weiterhin gegen den Anbieter getestet werden; die Redirect-URI-Prüfung hier ist nur ein lokaler Hinweis auf exakte Übereinstimmung.