OpenID Connect, aufbauend auf OAuth 2.0, ist das dominierende föderierte Identitätsprotokoll für moderne Stacks. Jeder große Unternehmens-IdP unterstützt es; jeder Cloud-Workforce-IdP bietet es an; jedes moderne Anwendungsframework stellt eine Bibliothek dafür bereit. Der vermeintlich leichte Teil ist die Annahme, dass ein paar Zeilen SDK-Code pro Anwendung ausreichen.
In der Praxis hat eine OIDC-Relying-Party, die echten Produktionsverkehr trägt, eine lange Liste von Dingen, die richtig gemacht werden müssen. Die Signatur des ID-Tokens muss gegen das vom IdP veröffentlichte JWKS unter Auswahl des korrekten Schlüssels über die kid verifiziert werden, und der Cache muss aufgefrischt werden, wenn der IdP Schlüssel rotiert. Der Audience-Claim muss mit der konfigurierten Client-ID übereinstimmen. Der Issuer muss mit dem konfigurierten erwarteten Issuer übereinstimmen. Die Gültigkeitsdauer muss mit einer begrenzten Toleranz für Uhrenabweichung geprüft werden. Die Nonce im ID-Token muss mit der Nonce übereinstimmen, die AAM in der Authorization-Anfrage gesendet hat — stimmt sie nicht überein, ist das kein Parsing-Fehler, sondern ein Replay-Versuch.
Die darunterliegende OAuth-2.0-Schicht hat ihre eigenen Fallstricke. Der State muss als CSRF an die Sitzung des Benutzers gebunden sein und eine kurze TTL haben. PKCE muss verwendet werden (vorzugsweise S256), damit ein abgefangener Authorization Code nicht durch den Angreifer eingelöst werden kann. Mixup-Angriffe — bei denen der Angreifer die Relying Party dazu bringt, mit dem falschen IdP zu sprechen — werden vereitelt, indem der Callback an einen bestimmten IdP gebunden und der Issuer entsprechend verifiziert wird. In einer reinen SDK-Integration ist keine dieser Verteidigungen automatisch.
Eine weitere Fehlerform ist, das OIDC-SDK direkt in jede Anwendung einzubetten. Jede Anwendung trägt in diesem Fall ihre eigenen Vertrauensentscheidungen, ihren eigenen JWKS-Cache, ihre eigenen Audit-Logs und ihre eigene IdP-Konfiguration separat. Eine einzige IdP-Änderung wird zu einem koordinierten Multi-Anwendungs-Rollout. MFA, Conditional Access, Gerätevertrauen und Logout-Verhalten werden für jede Anwendung separat und oft inkonsistent neu gelöst.
Die operative Seite ist ebenso wichtig. Das Aktualisieren des Discovery-Dokuments des IdP, das Behandeln der Signaturschlüssel-Rotation, unterschiedliches IdP-Routing pro Tenant, unterschiedliche Claim-Mappings für unterschiedliche Anwendungen und Logout-Flows sind keine nachträglich hinzugefügten Kleinigkeiten. Sie sind grundlegende Bestandteile dafür, dass die OIDC-Föderation sicher und nachhaltig läuft.
Der richtige Ort ist der Zugriffsrand. OIDC sollte an einem einzigen Punkt verifiziert und auf derselben Schicht wie Authentifizierung, MFA, Conditional Access, Gerätevertrauen und Backend-SSO verwaltet werden. So tragen Anwendungen nicht die Komplexität des Föderationsprotokolls; sie erhalten nur eine verifizierte, saubere und vertrauenswürdige Identität.
OIDC richtig zu verwalten heißt nicht nur, sich per SDK mit einem IdP zu verbinden. Es heißt, das ID-Token an einem einzigen Punkt — in derselben Engine wie MFA, Conditional Access, Gerätevertrauen und Backend-SSO — standardkonform zu verifizieren, zu auditieren und sicher zu den Anwendungen zu transportieren.
Ein einziges AAM-Gateway terminiert OIDC am Rand korrekt; der Rest der Zugriffs-Engine setzt darauf auf.
Authorization-Code-Flow mit PKCE, ID-Token-Signaturprüfung über JWKS, an die Nonce gebundene Replay-Verteidigung, an den State gebundene CSRF-Verteidigung, Durchsetzung von Audience/Issuer/Gültigkeit. Dieselbe Engine spricht reines OAuth 2.0 für IdPs, die kein ID-Token ausstellen; so teilen sich reine Token-Provider und vollständige OIDC-Provider eine einzige Codebasis.
Ein einziges AAM-Gateway kann unterschiedliche Anwendungen an unterschiedliche IdPs und unterschiedliche Tenants derselben Anwendung gleichzeitig an unterschiedliche IdPs routen. Die IdP-Auswahl erfolgt pro Anfrage aus dem Anwendungs- oder Tenant-Kontext — kein separates Gateway pro IdP, keine manuelle Auswahl für den Benutzer.
Die Nonce bindet das ID-Token an die Authorization-Anfrage, die es angefordert hat; der State bindet den Callback an die Sitzung des Benutzers; PKCE bindet die Code-Einlösung an den ursprünglichen Public Client. Keine davon ist ein optionales Flag, das der Integrator vergessen könnte — sie sind der Standard-Flow selbst.
Eine OIDC-Authentifizierung läuft nicht allein — sie wird mit Edge-MFA (falls der IdP keinen Step-up durchgesetzt hat), Conditional-Access-Ausdrücken, kontinuierlicher Vertrauensbewertung und Backend-SSO-Injektion zum Backend hin orchestriert. Das ID-Token wird zu einem Input für die AAM-Sitzung; es wird nicht zur gesamten Sitzung.
Standardkonforme OIDC-Relying-Party plus die operativen Funktionen, die Föderation im großen Maßstab sicher und verwaltbar machen.
AAM startet den OAuth-2.0-Authorization-Code-Flow mit standardmäßig aktiviertem PKCE — code_challenge_method=S256, ein frischer code_verifier für jede Anfrage, niemals wiederverwendet. Ein Angreifer, der den Verifier nicht erzeugt, kann einen abgefangenen Authorization Code nicht gegen Tokens einlösen. Plain PKCE bleibt für IdPs verfügbar, die es vorschreiben; S256 ist der konfigurierte Standard.
Wenn der Callback eintrifft, ruft AAM das JWKS des IdP ab, wählt den Signaturschlüssel aus dem kid-Header des ID-Tokens und verifiziert die Signatur des ID-Tokens mit dem im Header angegebenen Algorithmus (RS256 und der Rest der Standardfamilie). Ein Cache-Miss auf der kid frischt das JWKS sofort auf; so lässt eine IdP-Schlüsselrotation gültige Anmeldungen nicht hängen.
Der Audience-Claim des ID-Tokens muss die konfigurierte Client-ID enthalten; der Issuer muss mit dem konfigurierten erwarteten Issuer übereinstimmen; das Gültigkeitsfenster (exp/nbf) wird mit einer begrenzten Toleranz für Uhrenabweichung durchgesetzt; die Nonce muss mit der Nonce übereinstimmen, die AAM in der Authorization-Anfrage gesendet hat. Eine Nonce-Diskrepanz wird nicht als Parsing-Fehler, sondern als Replay-Signal mit eigenem Audit-Ereignis behandelt.
JWKS-Antworten werden in einem zwischen Worker-Prozessen und Gateway-Instanzen geteilten Speicher mit einer TTL von 1 Stunde zwischengespeichert. Ein Cache-Hit eliminiert den Netzwerk-Roundtrip bei jeder Anmeldung; ein Cache-Miss auf der angeforderten kid löst sofort einen Refresh von der JWKS-URI aus; so erzeugt eine routinemäßige IdP-Schlüsselrotation keine Anmeldeunterbrechung.
Standardmäßige OIDC-Authorization-Parameter sind erstklassige Konfiguration: scope (openid wird automatisch hinzugefügt), display für die IdP-Anmeldeerfahrung, max_age für erzwungene Re-Authentifizierung, ui_locales für lokalisierte IdP-Seiten und acr_values, um eine bestimmte Authentication-Context-Class anzufordern — nützlich, um Step-up-MFA-Durchsetzung vom IdP anzufordern.
Eingebaute Profile kommen mit vernünftigen Standardwerten für gängige Provider (Well-known-Endpoints, JWKS-URIs, Scope-Konventionen). Für jeden standardkonformen OIDC- oder OAuth-2.0-Provider bleibt der Custom-IdP-Pfad verfügbar, bei dem Endpoints, Scopes und Mappings manuell angegeben werden.
Nach der Signaturprüfung werden die Claims des ID-Tokens mit der Antwort vom userinfo-Endpoint des IdP zusammengeführt. Bei Konflikt gelten die signierten ID-Token-Claims gegenüber den unsignierten userinfo-Feldern als vorrangig; so kann ein Angreifer, der die userinfo-Antwort manipuliert, einen signierten Identitäts-Claim nicht stillschweigend ändern.
RP-Initiated Logout (der signierte Front-Channel-Logout der OIDC-Spezifikation) und Back-Channel-Logout für Sitzungsbeendigungs-Benachrichtigungen vom IdP sind auf der Roadmap. Die dynamische OIDC-Client-Registrierung — die Inbetriebnahme einer neuen Anwendung durch automatische Registrierung beim IdP — ist ebenfalls geplant. Die Sitzungs- und Audit-Infrastruktur ist bereits darauf ausgelegt, diese Flows zu bedienen.
Die Mechanik, die eine OIDC-Föderation sicher, aktuell und beobachtbar hält.
Der OAuth-State-Parameter wird gegen die Sitzung des Benutzers mit einer TTL von 10 Minuten gespeichert. Wenn der Callback eintrifft, verifiziert AAM, dass der State zur selben Sitzung gehört, die den Flow gestartet hat — ein Angreifer, der einen State-Wert in den Browser eines anderen Benutzers wiedereinspielt, wird mit einem OAUTH_STATE_MISMATCH-Audit-Ereignis abgelehnt.
Wenn die ID-Token-Signaturprüfung aus einem operativen Grund übersprungen wird — JWKS nicht erreichbar, keine passende kid, defekter JWK, fehlende JWKS-URI — protokolliert ein dediziertes Audit-Ereignis die spezifische Grundursache. Operatoren können einen temporären JWKS-Ausfall von einer Fehlkonfiguration oder einem nicht unterstützten Schlüsseltyp unterscheiden, ohne Runtime-Logs erneut durchzulesen.
ID-Tokens tragen iat-, nbf- und exp-Zeitstempel. Reale Uhren driften; AAM wendet eine begrenzte Toleranz für Uhrenabweichung an (Standard 60 Sekunden für den darunterliegenden JWT-Validator); so lehnt eine kleine Abweichung keine gültigen Anmeldungen ab, während große Abweichungen — ein Indikator für Fehlkonfiguration oder Replay — dennoch abgelehnt werden.
Token-Tausch- und userinfo-Anfragen an den IdP verwenden begrenzte Verbindungs-, DNS- und Gesamt-Timeouts; so kann ein langsamer oder nicht reagierender IdP keine Gateway-Worker belegen. Der Token-Tausch läuft mit einem Gesamtbudget von 30 Sekunden; userinfo läuft mit einem Budget von 15 Sekunden; beide haben kürzere Verbindungs- und DNS-Budgets; so scheitern Fehlschläge schnell.
Jeder Schritt des OIDC-Flows — Flow-Start, Callback-Erfolg, Token-Tausch (welche Tokens zurückkamen), Ergebnis der ID-Token-Signaturprüfung, Ergebnis des JWKS-Abrufs — wird mit einer Korrelations-ID protokolliert, die auf die AAM-Sitzung und das/die dahinterliegende(n) Backend(s) zurückverweist. Die Frage „Wer hat sich wann über welchen IdP angemeldet?" wird mit einer einzigen Abfrage beantwortet.
Automatische OIDC-Provider-Discovery über den Endpoint .well-known/openid-configuration und eine Warnung an den Operator, wenn sich entdeckte Endpoints oder Signaturschlüsselsätze ändern, sind auf der Roadmap. JWKS-Rotations-Telemetrie — Metriken zum Signaturschlüsselwechsel, Hinweise zu den verbleibenden Tagen bis zum Ablauf des aktuellen Schlüssels, automatische Rotations-Runbooks — ist ebenfalls geplant.
Bestehende Unternehmens-IdPs, die die Belegschaft bereits über OIDC authentifizieren. AAM klinkt sich als Relying Party ein, ohne vom IdP-Team irgendeine Änderung zu verlangen. Neue Anwendungen treten der Föderation bei, indem sie einen Eintrag in AAM hinzufügen — nicht indem sie jeder Codebasis ein neues OIDC-SDK hinzufügen.
Interne Tools, die gegen den Google-Workspace-Tenant der Organisation authentifizieren, oder Entwickler-Tools, die GitHub als IdP verwenden. AAM spricht OIDC mit Google und OAuth 2.0 mit GitHub — aus derselben Engine — und bildet jedes auf das kanonische AAM-Sitzungsformat ab.
SaaS-Anwendungen, bei denen jeder Kunde seinen eigenen OIDC-IdP mitbringt. Ein einziges AAM-Gateway hält alle Tenants vorgelagert; der Verkehr jedes Tenants wird an den IdP dieses Tenants geroutet. Einen Tenant hinzuzufügen bedeutet, eine Konfigurationsänderung im IdP-Registry-Speicher vorzunehmen — kein Deployment.
Manche IdPs authentifizieren, setzen aber Step-up-MFA oder Conditional Access nicht für jede Anwendung gleichermaßen durch. AAM akzeptiert die Authentifizierung des IdP, setzt dann seine eigene MFA, Conditional-Access-Ausdrücke und kontinuierliche Vertrauensbewertung darauf auf, bevor es Zugriff auf die Anwendung gewährt.
Lassen Sie uns AAM mit Ihrem OIDC-IdP verbinden — Unternehmen, Cloud oder selbst gehostet — und den Rest der Zugriffs-Engine mit MFA, Conditional Access, Gerätevertrauen und Backend-SSO auf dem verifizierten ID-Token aufsetzen.