Legt Vertrauensgrenzen, Token oder Anmeldeinformationen, Missbrauchskontrollen, Ablauf, Widerruf und Bedrohungsminderungen für OpenID Connect fest. Es definiert Annahmegrenzen und beobachtbare Fehlerbelege, während umgebungsspezifische Grenzen konfigurierbar bleiben.
Paketstatus: Referenzkontext bereit für menschliche Überprüfung. Der Vertrag und die Testszenarien sind abgeschlossen, es wird jedoch nicht behauptet, dass eine übernehmende Implementierung diese bestanden hat.
Entscheidung
Für OpenID Connect wird ein serverseitiger Anmeldeinformations- und Sitzungslebenszyklus mit expliziter Zusicherung übernommen. Die Kontrolle wird auf der vertrauenswürdigen Serverseite durchgesetzt, standardmäßig verweigert, und Bedrohungsannahmen, Missbrauchsgrenzen, Belege und Wiederherstellung werden definiert. Dieses Paket ist ein Referenzvertrag: Das übernehmende Team muss numerische Grenzen, Anbieter, Rechtsordnungen und operative Verantwortliche anhand von Belegen aus der eigenen Umgebung auswählen.
Umfang
- Die OpenID Connect-Akteure, Eingaben, Ausgaben, Zustände, Richtlinien- oder Schemaversionen und extern sichtbare Ergebnisse, die durch diesen Sicherheitsblock beschrieben werden.
- Primäre und alternative Schnittstellen, Hintergrundarbeiten, Caches, Integrationen, Supportpfade und Belege, die dieselbe Grenze ausüben können.
- Übernahmespezifische Konfiguration, Rollout, Wiederherstellung und Verifizierungsverantwortlichkeiten, die erforderlich sind, um die Referenz sicher anzuwenden.
Außerhalb dieses Blocks
- Die Wahl eines universellen Anbieters, Frameworks, einer Rechtsordnung, eines numerischen Schwellenwerts, einer Aufbewahrungsfrist oder eines Service-Level-Objectives für jeden Übernehmer.
- Die Behauptung, dass verpackte Szenarien gegen eine nachgelagerte Implementierung ausgeführt wurden oder dass diese Referenz eine rechtliche, sicherheitsbezogene oder barrierefreie Zertifizierung gewährt.
Vertrag
- Speichern Sie nur geschützte Anmeldeinformationen, rotieren Sie Signatur- und Wiederherstellungsgeheimnisse und halten Sie Anmeldeinformationen aus URLs, Protokollen, Analysen und Supportansichten fern.
- Binden Sie Ausstellung, Nutzung, Ablauf, Widerruf, Wiederherstellung und Wiedergabehandling an ein benanntes Subjekt und die beabsichtigte Aktion.
- Geben Sie öffentlichkeitsresistente Antworten zurück, während interne Gründe und Korrelationsdaten für Support und Missbrauchsreaktion erhalten bleiben.
- Überprüfen Sie sensible Aktionen nach Änderungen an Subjekt, Gerät, Authentifikator, Risiko oder Sitzungsstatus erneut, anstatt einem veralteten Login dauerhaft zu vertrauen.
- Behandeln Sie alle Client-, Callback-, Datei-, Modell- und Telemetriedatenfelder als nicht vertrauenswürdig, bis sie für die beabsichtigte Aktion authentifiziert und validiert sind.
- Erfordern Sie eine zweite unabhängige Absicherung für hochwirksame Pfade, bei denen eine Kompromittierung eines Parsers, einer Anmeldeinformation oder eines Anbieters sonst entscheidend wäre.
- Validieren Sie Aussteller, Publikum, Signatur, Ablauf, Nonce und Bindung der Autorisierungsantwort; ordnen Sie externe Subjekte mit Aussteller als zusammengesetzte Identität zu.
- Kontoverknüpfung erfordert eine authentifizierte lokale Entscheidung und kann nicht allein auf eine nicht verifizierte übereinstimmende E-Mail vertrauen.
Implementierungsleitfaden
- Bedrohen Sie normale, Wiedergabe-, Enumerations-, Mandantenübergreifende, Automatisierungs- und Abhängigkeitsverschlechterungspfade vor der Implementierungsüberprüfung.
- Modellieren Sie OpenID Connect-Eingaben, -Ausgaben, Akteure, Zustände, Invarianten, Nebeneffekte und Belege, bevor Sie Framework- oder Anbieterdetails auswählen.
- Speichern Sie die anwendbare OpenID Connect-Vertrags- oder Richtlinienversion mit materiellem Zustand, damit Migrationen, Wiedergabe und Supportentscheidungen zuordenbar bleiben.
- Führen Sie den Pfad hinter kontrolliertem Rollout ein, vergleichen Sie erwartete und beobachtete Ergebnisse und behalten Sie eine getestete Wiederherstellungsroute, bis Übernahmebelege vollständig sind.
Fehlerbehandlung und Schutzmaßnahmen
- Fehlende, abgelaufene, wiederholte oder widersprüchliche Authentifizierungsbelege verweigern die Aktion und folgen einem ratenbegrenzten Wiederherstellungspfad.
- Ungültiger oder widersprüchlicher OpenID Connect-Zustand wird abgelehnt oder isoliert; die Implementierung rät niemals einen Wert, der Autorität erweitert oder eine Wirkung dupliziert.
- Wiederholungen sind begrenzt und verwenden eine dauerhafte Identität; nach Erschöpfung erreicht die Arbeit einen überprüfbaren Endzustand mit verantwortlichem Eigentümer.
Verifizierung und Betrieb
- Verwenden Sie gepaarte Zulassungs- und Verweigerungsfälle an jeder Vertrauensgrenze und bestätigen Sie, dass der Verlust der Kontrollabhängigkeit zu einem geschlossenen Fehler führt.
- Überwachen Sie OpenID Connect-Erfolg, Verweigerung, Validierungsfehler, Abhängigkeitsfehler, Wiederholungsermüdung und Wiederherstellung nach Vertragsversion ohne sensible Nutzlastdimensionen.
- Führen Sie gepaarte positive und negative Tests nach Richtlinien-, Schema-, Abhängigkeits-, Migrations- oder Grenzänderungen erneut aus und bewahren Sie die resultierenden Belege auf.
Übernahmeannahmen
- Namen und Werte im Beispiel sind ein konkretes Fixture, keine universellen Standardwerte; Übernehmer ersetzen sie durch dokumentierte Belege und Verantwortlichkeit.
- Das übernehmende System kann authentifizierte Identität, dauerhafte Betriebs- oder Versionsaufzeichnungen, begrenzte Telemetrie und einen kontrollierten Änderungsweg bereitstellen.
Die ausführbar aussehenden Beispiele in diesem Paket sind Fixtures und Akzeptanzverträge. Führen Sie den Sammlungsvalidator aus, um Struktur und Metadaten zu prüfen, übersetzen und führen Sie dann die Szenarien im Zielrepository aus, bevor Sie Implementierungsbelege aufzeichnen.
Referenzen
- NIST SP 800-63B-4, Authentication and Authenticator Management (gültig ab 2026-09-08)
- OpenID Connect Core 1.0