Überblick
WebAuthn, FIDO2, OIDC, SAML und SCIM erscheinen oft in derselben Anmeldearchitektur, lösen aber unterschiedliche Probleme auf verschiedenen Ebenen. Werden sie gleichgesetzt, entstehen Lücken: Eine Anwendung kann SSO ohne phishingresistente Authentifizierung haben, SCIM-Deaktivierung ohne sofortiges Sitzungsende oder einen Passkey beim IdP, während die Zielanwendung nichts über WebAuthn weiß.
Eine ausgereifte Workforce-Identity-Architektur kombiniert die Ebenen. WebAuthn und FIDO2 regeln, wie ein Konto authentifiziert wird. OIDC oder SAML überträgt Authentifizierungsergebnis und Identity Claims an eine Anwendung. SCIM erstellt und aktualisiert Identity-Ressourcen. Die Anwendung setzt weiterhin Autorisierung durch und verwaltet ihre Sitzungen.
Jeder Standard in einem Satz
| Standard | Ebene | Was er leistet | Was er nicht leistet |
|---|---|---|---|
| WebAuthn | API zwischen Relying Party und Client-Plattform | Registriert und verifiziert Public-Key-Credentials, die an eine Relying Party gebunden sind | Definiert weder Föderation, Provisionierung, Anwendungsautorisierung noch allgemeines Sitzungsmanagement |
| FIDO2 | Standardfamilie | Kombiniert WebAuthn mit CTAP zwischen Client-Plattform und externem Authenticator | Ist kein Föderations- oder Provisionierungsprotokoll und kein UI-Element |
| OpenID Connect | Föderierte Authentifizierung | Ergänzt OAuth 2.0 um eine Identity-Schicht, damit ein Client ein Authentifizierungsereignis und Claims in einem ID Token prüfen kann | Schreibt nicht vor, wie der OpenID Provider den Benutzer authentifiziert oder das Anwendungskonto provisioniert |
| SAML 2.0 | Föderation und Web-SSO | Überträgt Authentifizierung, Attribute und Sicherheitsinformationen in XML-Assertions und Protokollnachrichten | Führt die vorgelagerte Benutzerauthentifizierung nicht selbst aus und provisioniert kein Anwendungskonto |
| SCIM 2.0 | Identity-Lifecycle | Verwaltet Benutzer, Gruppen und weitere Identity-Daten über HTTP-Ressourcen und Schemas | Authentifiziert keine Endbenutzer, definiert keine Anwendungsautorisierung und garantiert kein Ende aktiver Sitzungen |
So arbeiten die Ebenen zusammen
- 1. Konto provisionieren. Ein SCIM-Client erstellt oder aktualisiert Benutzerkonto und Gruppenzuweisungen in der Zielanwendung, sofern die benötigten Operationen und Attribute unterstützt werden.
- 2. Anwendungszugriff beginnen. Der Benutzer öffnet die Anwendung, die Authentifizierung an einen vertrauenswürdigen IdP delegiert.
- 3. Föderation starten. Die Anwendung sendet eine OIDC Authorization Request oder SAML Authentication Request gemäß unterstütztem Profil.
- 4. Beim IdP authentifizieren. Der IdP kann WebAuthn/FIDO2 verwenden, um eine frische, an die Relying Party gebundene Assertion zu verifizieren. Gerätegebundene Passkeys bleiben in einem Authenticator; synchronisierte Passkeys können geschütztes Schlüsselmaterial über den Provider replizieren.
- 5. Föderationsantwort prüfen. Die Anwendung validiert OIDC ID Token oder SAML Response einschließlich Issuer, Audience, Signatur, Zeitbedingungen, Request-Korrelation und weiterer Anforderungen.
- 6. Anwendungssitzung erstellen. Die Anwendung ordnet Subject und Claims einem lokalen Konto zu, autorisiert und stellt eine eigene Sitzung aus. Laufzeit, Widerruf und Logout bleiben Anwendungsaufgaben.
- 7. Lebenszyklusänderungen verarbeiten. SCIM kann das Konto deaktivieren oder ändern; Entitlement-Entzug und Beendigung aktiver Sitzungen müssen separat geprüft werden.
Wo jeder Standard passt
- Authentifizierung: WebAuthn und FIDO2. Der Authenticator signiert eine frische Challenge für die Relying Party. WebAuthn transportiert RP-ID- und Origin-Kontext, CTAP verbindet die Client-Plattform mit externen Authenticators. Der private Schlüssel wird bei der Authentifizierung nicht an die Relying Party gesendet.
- Anwendungsföderation: OIDC oder SAML. Beide lassen eine Anwendung einem beim IdP durchgeführten Authentifizierungsereignis vertrauen. OIDC ist in modernen Web- und nativen Anwendungen verbreitet; SAML wird häufig für Enterprise-Web-SSO genutzt. Nach Kompatibilität folgen Profil, Sicherheitskontrollen und Implementierungsqualität.
- Lifecycle-Automatisierung: SCIM. SCIM standardisiert HTTP-Operationen und Schemas für Benutzer und Gruppen. Es reduziert manuelle Arbeit, doch Mappings, Durchsetzung, Retries, Teilfehler und Sitzungsende müssen betrieblich validiert werden.
Häufige Fehler vor dem Rollout
- SSO als Nachweis starker Authentifizierung behandeln. OIDC oder SAML kann schwache wie starke vorgelagerte Authentifizierung föderieren. Verlangen und prüfen Sie das passende Assurance-Niveau.
- OAuth 2.0 allein als Identitätsnachweis nutzen. OAuth ist ein Autorisierungsframework. OpenID Connect ergänzt Authentifizierungssemantik, ID Token und standardisierte Identity Claims.
- FIDO2-Unterstützung als binär annehmen. Eine Anwendung kann WebAuthn direkt, nur über einen IdP oder gar nicht unterstützen. Testen Sie den End-to-End-Pfad je Anwendung.
- Annehmen, ein synchronisierter Passkey verlasse nie ein Gerät. Gerätegebundene Credentials bleiben in einem Authenticator. Synchronisierte Passkeys replizieren geschütztes Schlüsselmaterial bewusst über einen Credential-Provider.
- SCIM wegen kleiner Teamgröße auslassen. Manuelle Prozesse können unabhängig von der Teamgröße zu Verzögerungen und verwaistem Zugriff führen. Bewerten Sie Fehlerbehandlung und Nachweise.
- Annehmen, SCIM-Deaktivierung beende jede Sitzung. Die Deaktivierung eines Benutzerdatensatzes garantiert keinen sofortigen Widerruf vorhandener Cookies oder Tokens.
- SAML versus OIDC nur als Markenwahl behandeln. Prüfen Sie nach Kompatibilität Flow, Profil, Redirect- und Audience-Validierung, Signatur, Verschlüsselung, Schlüsselrotation, Claims, Logout und Sitzungsverhalten.
Was zu bewerten ist
- Authentifizierungsstärke. Zugelassene Methoden, Durchsetzung der Phishingresistenz und Übermittlung oder Anforderung von Authentifizierungskontext.
- Föderationsabdeckung. Welche Anwendungen OIDC, SAML, beide oder keines unterstützen und welche Flows, Bindings, Profile, Algorithmen und Logout-Mechanismen implementiert sind.
- Identity-Korrelation. Wie stabile Subject Identifier, NameIDs, E-Mail-Adressen und Linking-Regeln doppelte oder falsch gebundene Konten verhindern.
- Claims und Attribute. Welche Daten freigegeben, minimiert, transformiert, signiert, verschlüsselt und für Autorisierung genutzt werden.
- Provisionierungsverhalten. Unterstützte SCIM-Ressourcen und Operationen, Gruppen- und Entitlement-Mappings, Retries, Teilfehler und Deaktivierungsdauer.
- Sitzungskontrollen. Wie Anwendungen Sitzungen erstellen, erneuern, widerrufen und beenden und ob IdP-Risikoereignisse vorhandene Sitzungen beeinflussen.
- Audit-Nachweise. Ob Registrierung, Authentifizierung, Föderation, Provisionierung, Autorisierung, Deaktivierung und Sitzungswiderruf korreliert werden können.
Abbildung in Gideon Identity
Gideon Identity nutzt WebAuthn und FIDO2 für phishingresistente Workforce-Authentifizierung, unterstützt OIDC- und SAML-Föderation für kompatible Anwendungen und verwendet SCIM, soweit unterstützt, zur Automatisierung von Lifecycle-Änderungen. Die konkrete Bereitstellung hängt von Protokollfähigkeiten, Mappings und Sitzungskontrollen jeder Anwendung ab.
Weiterführende Inhalte
- Beginnen Sie mit Passkeys für Workforce Identity: Einkaufsleitfaden.
- Vergleichen Sie Credential-, Geräte- und Sitzungskontrollen in Gerätegebundene Authentifizierung vs. konventionelle MFA.
- Lesen Sie zu Lebenszyklusnachweisen Trusted Authenticator Lineage.
- Verstehen Sie Plattform-Schlüsselschutz in Wie Secure Enclave und TPM den Workforce-Zugriff verändern.
- Entdecken Sie Gideon Identity.
Primärquellen
- Die FIDO Alliance beschreibt FIDO2 und Passkey-Modelle in ihrer Passkey-Dokumentation.
- Die OpenID Foundation definiert OIDC in OpenID Connect Core 1.0.
- OASIS definiert SAML in der SAML 2.0 Technical Overview.
- Die IETF definiert SCIM in RFC 7644.
So nutzen Sie diese Ressource
Ordnen Sie jede Anforderung der richtigen Ebene zu, inventarisieren Sie Anwendungsfähigkeiten und definieren Sie messbare Kriterien für Authentifizierung, Föderation, Provisionierung, Autorisierung und Sitzungslebenszyklus.