Ressourcen · 43
OAuth und OpenID Connect: Überprüfung einer End-to-End-Integration
Anmelde-, Delegierungs- und Datenberechtigungen trennen, dann Weiterleitungen, Token, Sitzungen und Widerruf testen.
Aktualisiert · 3 min
Wozu dieser Leitfaden beiträgt
- Identität von Autorisierung trennen
- Unbeabsichtigte Weiterleitungen und Token ablehnen
- Testen Sie Ablehnungen ebenso sorgfältig wie Erfolge
- Überprüfen Sie die Entfernung des Zugangs nach Abreise oder Vorfall
Kurzcheck
- Welche Anbieter und Emittenten werden erwartet?
- Ist die Weiterleitungs-URI genau registriert?
- Wird ein ID-Token fälschlicherweise als Zugriffstoken verwendet?
- Überprüft jede Ressource den Besitz?
- Welcher Zugriff überlebt den Widerruf?
Schritt-für-Schritt-Anleitung
- 1
Zeichnen Sie den bereitgestellten Flow
Identifizieren Sie öffentlichen oder vertraulichen Client, Browser, Autorisierungsserver, API und OIDC-Anbieter. Erfassen Sie, wohin Codes und Token reisen, wer sie speichert und welche Rollen gewährt werden. Ein Verkaufsdiagramm stellt nicht den tatsächlichen Einsatz dar.
Lieferinhalt: Fluss, Vertrauensgrenzen und Komponentenbesitzer.
- 2
Überprüfen Sie die Anmeldetransaktion
Verwenden Sie den für den Client geeigneten Codefluss mit PKCE. Überprüfen Sie S256, Transaktionsbindung, registrierte Weiterleitungen und Schutz vor gefälschten Anfragen. Testen Sie einen unerwarteten URI, einen falschen Verifizierer, einen wiederholten Code und einen unerwarteten Aussteller. RFC 9700 trennt Anforderungen und Empfehlungen nach Kundentyp.
Lieferbar: Erlaubte und verweigerte Testergebnisse.
- 3
Validieren Sie das richtige Token
Die API validiert ihr Zugriffstoken nach Format und Anbieterregeln: Signatur oder Selbstprüfung, Aussteller, Zielgruppe, Ablauf und Berechtigungen. Der OIDC-Client validiert das Identitätstoken separat. Eine gültige Signatur stellt nicht sicher, dass das Token zu dieser API gehört.
Lieferinhalt: Validierungsvertrag sowie Zielgruppen- und Ablauftests.
- 4
Geschäftsberechtigungen prüfen
Testen Sie ein Objekt, das einem anderen Konto gehört, eine niedrigere Rolle, ein privates Feld und einen Verwaltungsvorgang. Ein Bereich oder ein authentifiziertes Gateway ersetzt keine serverseitigen Überprüfungen der angeforderten Ressource. Verwenden Sie autorisierte Testkonten und -daten.
Lieferinhalt: Rolle, Objekt, Operation und Expected-Denial-Matrix.
- 5
Ausübungsablauf und Widerruf
Separate lokale Sitzung, Provider-Sitzung, Zugriffstoken und Aktualisierungstoken. Testabgang, Geräteverlust, Rollenwechsel, Signaturschlüsselrotation und Anbieterausfall. Dokumentieren Sie die verbleibende Zugriffszeit, anstatt davon auszugehen, dass durch die Abmeldung sofort alles widerrufen wird.
Lieferinhalt: Zeitleiste und Ausnahmen für die Zugriffsentfernung.
- 6
Beobachten, ohne Geheimnisse preiszugeben
Transaktionsreferenz, Validierungsentscheidung, Fehlerkategorie und Konfigurationsversion protokollieren. Schließen Sie Codes, Token und Geheimnisse aus. Bereiten Sie Diagnose, Herunterfahren der Integration und Rollback auf eine validierte Konfiguration vor; Wiederholungstests nach Anbieterwechseln.
Liefergegenstand: Betriebsanweisungen und Regressionsprüfungen.
Fiktives Arbeitsbeispiel
Beispielhafte Situation
Beispielhafte Situation: Zwei Clients nutzen einen Identitätsanbieter. Ein für den ersten gültiges Token wird der API des zweiten Clients vorgelegt.
Entscheidung und erwartete Beweise
Die API lehnt die falsche Zielgruppe ab, zeichnet einen tokenfreien Trace auf und gibt keine Daten zurück. Das Leugnen wird zum Regressionstest.
Unterscheiden Sie die Mechanismen
| Mechanismus | Zweck | Überprüfung oder Einschränkung |
|---|---|---|
| OAuth 2.0 | Ressourcenzugriff delegieren | Serverseitige Objektberechtigungen |
| OpenID Connect | Identität durch validiertes ID-Token herstellen | Emittenten-, Zielgruppen- und Transaktionsvalidierung |
| Anwendungssitzung | Anwendungsanmeldung beibehalten | Ablauf-, Ungültigkeits- und Sitzungsschutz |
Managementindikatoren
| Indikator | Was es misst | Erste Aktion |
|---|---|---|
| Korrekte Dementis | Verbotene Fälle tatsächlich blockiert | Beheben Sie jede unerwartete Annahme |
| Sperrverzögerung | Zeit bis zum Verschwinden des relevanten Zugriffs | Sitzungen und Token separat prüfen |
| Validierungsfehler | Ablehnungen nach Grund und Version | Trennen Sie Angriffe von Konfigurationsfehlern |
Häufige Fallstricke
- Authentifizierung mit Autorisierung verwechselt
- Akzeptieren einer beliebigen Audienz nach Überprüfung der Signatur
- Registrieren breiter Weiterleitungs-URIs
- Protokollierungstokens für einfacheres Debuggen
Häufig gestellte Fragen
Ersetzt PKCE jede Steuerung?
Nein. Es schützt den Codeaustausch im vorgesehenen Ablauf; Token-Validierung, Weiterleitungen, Geschäftsautorisierung und Sitzungen müssen noch überprüft werden.
Ist ein JWT eine Berechtigung?
JWT ist ein Format. Ansprüche werden erst nach Validierung und Anwendung Ihrer API-Regeln nutzbar.
Sollte die Validierung von Grund auf neu erstellt werden?
Bevorzugen Sie eine gepflegte Bibliothek und Provider-Dokumentation und testen Sie dann Ihre Konfiguration. Eine korrekte Bibliothek kann immer noch falsch konfiguriert werden.
Offizielle Referenzen
Die Referenzen unterstützen die Methode. Passen Sie die Prüfungen an Ihren Kontext an; sie stellen keine Zertifizierung dar. Originalreferenztitel und Quelldokumente können in einer anderen Sprache verfasst sein.
