Föderierte Identitäten: SAML, OAuth und OpenID Connect

In modernen Unternehmen müssen Mitarbeitende auf Dutzende von Anwendungen zugreifen – auf Cloud-Apps, SaaS-Tools, Partnerportale und interne Systeme –, die jeweils von unterschiedlichen Organisationen betrieben werden können. Für jede Anwendung separate Konten anzulegen und zu verwalten, ist unsicher (eine Vielzahl von Anmeldedaten) und ineffizient. Föderierte Identitäten lösen dieses Problem, indem sie einem Identity Provider (IdP) – einer vertrauenswürdigen, maßgeblichen Identitätsquelle – ermöglichen, Benutzer zu authentifizieren und diese authentifizierte Identität über Organisationsgrenzen hinweg mit Service Providern (SPs) zu teilen. Benutzer authentifizieren sich einmal und erhalten Zugriff auf mehrere Systeme, ohne ihre Anmeldedaten erneut eingeben zu müssen.

Single Sign-On (SSO) ermöglicht es Benutzern, sich einmal zu authentifizieren und innerhalb einer Sitzung auf mehrere Anwendungen zuzugreifen, ohne sich erneut authentifizieren zu müssen. Der Benutzer meldet sich beim Identity Provider (unternehmensweites Active Directory, Okta, Azure AD) an, erhält ein Sitzungstoken oder eine Assertion und legt dieses Token bei jedem besuchten Service Provider vor. SSO erhöht die Sicherheit, weil Benutzer weniger Passwörter verwalten müssen (was die Wiederverwendung von Passwörtern reduziert), Richtlinien für die zentrale Authentifizierung durchgesetzt werden können und der Zugriff auf alle integrierten Anwendungen sofort entzogen werden kann, sobald ein Konto auf IdP-Ebene deaktiviert wird.

SAML (Security Assertion Markup Language) 2.0 ist der XML-basierte offene Standard zum Austausch von Authentifizierungs- und Autorisierungsdaten zwischen Identity Providern und Service Providern. Der SAML-Ablauf: (1) Der Benutzer greift auf einen Service Provider zu (z. B. Salesforce), (2) der SP leitet zum Identity Provider weiter (z. B. Okta), (3) der Benutzer authentifiziert sich beim IdP, (4) der IdP stellt eine signierte XML-SAML-Assertion aus, die die Identität und Attribute des Benutzers enthält, (5) die Assertion wird an den SP zurückgegeben, (6) der SP validiert die Signatur der Assertion mithilfe des öffentlichen Schlüssels des IdP und gewährt Zugriff. SAML wird häufig für Enterprise-SSO in Webanwendungen eingesetzt.

An einer SAML-Föderation sind drei Parteien beteiligt. Der Principal ist der Benutzer (oder das System), der Zugriff anfordert – er initiiert den Authentifizierungsprozess. Der Identity Provider (IdP) ist die maßgebliche Identitätsquelle, die den Principal authentifiziert und Assertions ausstellt – Beispiele sind Microsoft Azure AD, Okta, Ping Identity und ADFS. Der Service Provider (SP) verarbeitet die Assertion und gewährt auf dieser Grundlage Zugriff – Beispiele sind Salesforce, Google Workspace, AWS und jede SAML-fähige Anwendung. SP und IdP schaffen im Voraus Vertrauen, indem sie Metadaten mit den Endpunkt-URLs und Signaturzertifikaten des jeweils anderen austauschen.

OAuth 2.0 ist ein Autorisierungsframework (kein Authentifizierungsprotokoll), das einer Drittanbieteranwendung ermöglicht, im Namen eines Benutzers auf Ressourcen zuzugreifen, ohne dessen Anmeldedaten offenzulegen. Ein typischer Anwendungsfall: „Diese Fotobearbeitungs-App darf auf Ihre Google Fotos zugreifen.“ OAuth 2.0 führt vier Rollen ein: den Ressourcenbesitzer (Benutzer), den Client (Drittanbieter-App), den Autorisierungsserver (stellt Tokens aus) und den Ressourcenserver (stellt die geschützte Ressource bereit). Der Benutzer autorisiert den Client, der ein Access Token erhält und es dem Ressourcenserver vorlegt – ohne jemals das tatsächliche Passwort des Benutzers zu benötigen.

Der Authorization Code Flow ist der sicherste OAuth-2.0-Ablauf für Webanwendungen. Der Ablauf: (1) Der Client leitet den Benutzer mit den angeforderten Scopes zum Autorisierungsserver weiter; (2) der Benutzer authentifiziert sich beim Autorisierungsserver und erteilt seine Zustimmung; (3) der Autorisierungsserver leitet mit einem kurzlebigen Authorization Code zurück; (4) der Client tauscht den Code über einen Server-zu-Server-Aufruf mit Client-Anmeldedaten gegen ein Access Token (und optional ein Refresh Token) ein; (5) der Client verwendet das Access Token, um den Ressourcenserver aufzurufen. Der Codeaustausch findet serverseitig statt. Dadurch wird verhindert, dass das Access Token im Browserverlauf oder in Protokollen offengelegt wird.

OpenID Connect (OIDC) ist eine auf OAuth 2.0 aufbauende Authentifizierungsschicht. OAuth stellt nur Autorisierung bereit (Access Tokens weisen nach, was der Client tun darf); OIDC ergänzt Authentifizierung (ein ID Token weist nach, wer der Benutzer ist). OIDC ergänzt den OAuth-Ablauf um den openid-Scope und gibt neben dem Access Token ein signiertes JWT (JSON Web Token) ID Token zurück. Das ID Token enthält Claims (Name, E-Mail-Adresse, sub [Subject Identifier]), die den Benutzer identifizieren. OIDC ist inzwischen das vorherrschende Protokoll für verbraucherorientiertes SSO – die Schaltflächen „Mit Google/Apple/Microsoft anmelden“ verwenden sämtlich OIDC.

JSON Web Tokens (JWT) sind ein kompaktes, URL-sicheres Format zur Darstellung von Claims zwischen Parteien. Ein JWT besteht aus drei durch Punkte getrennten, base64url-codierten Teilen: Header (Algorithmus und Tokentyp), Payload (Claims: iss, sub, aud, exp, iat und benutzerdefinierte Claims) und Signature (kryptografische Signatur zur Überprüfung der Integrität des Tokens). JWTs sind eigenständig – der Ressourcenserver kann sie überprüfen, ohne den Autorisierungsserver aufzurufen. Das verbessert die Leistung und ermöglicht zustandslose Architekturen. Die entscheidende Sicherheitsanforderung lautet: Überprüfen Sie immer die JWT-Signatur und kontrollieren Sie die Claims exp (Ablaufzeit) und aud (Zielgruppe).

Für die Security+-Prüfung ist es entscheidend zu verstehen, wann welcher Standard zum Einsatz kommt. SAML 2.0: Enterprise-SSO für Webanwendungen, browserbasierte Abläufe und XML-Assertions. Veraltet, aber in Unternehmen weit verbreitet. OAuth 2.0: API-Autorisierung – Drittanbieter-Apps wird begrenzter Zugriff auf Ressourcen gewährt. Authentifiziert Benutzer nicht direkt. OIDC: Authentifizierung für Verbraucher und moderne Unternehmen (SSO), aufgebaut auf OAuth 2.0. Gibt JWT-ID-Tokens zurück, die den Benutzer identifizieren. In der Praxis verwenden Unternehmensumgebungen häufig SAML für das Anwendungs-SSO und OIDC für die API- bzw. Mobil-Authentifizierung. Moderne Cloud-native-Umgebungen bevorzugen OIDC gegenüber SAML wegen des JSON/JWT-Formats und der besseren Unterstützung mobiler Geräte.

Föderierte Identitätssysteme bringen spezielle Angriffsvektoren mit sich. Replay-Angriffe auf Assertions: Ein Angreifer fängt eine SAML-Assertion ab und verwendet sie erneut, um Zugriff zu erlangen. Dagegen helfen kurze Gültigkeitsdauern und nur einmal verwendbare Assertion-IDs. XML Signature Wrapping (XSW): Bei SAML können Angreifer signiertes XML bisweilen so manipulieren, dass sich Claims ändern, während die Signatur für den ursprünglichen Inhalt gültig bleibt. JWT-Algorithmusverwechslung: Akzeptiert ein Server sowohl den asymmetrischen Algorithmus RS256 als auch den symmetrischen Algorithmus HS256, kann ein Angreifer JWTs fälschen, indem er den öffentlichen Schlüssel des Servers als HMAC-Secret für HS256 verwendet. Validieren Sie immer, dass der Algorithmus im Header dem erwarteten Algorithmus entspricht. Open Redirectors: OAuth-Redirect-URIs müssen exakt abgeglichen werden, um Token-Diebstahl durch Weiterleitung auf vom Angreifer kontrollierte Websites zu verhindern.

Die Identitätsföderation in Unternehmen erfordert häufig die Synchronisierung von Identitätsdaten zwischen Systemen. SCIM (System for Cross-domain Identity Management) ist ein REST-API-Standard zur Automatisierung der Benutzerbereitstellung und -aufhebung zwischen einem Identity Provider und verbundenen Service Providern. Wird ein neuer Mitarbeiter zu Azure AD (IdP) hinzugefügt, erstellt SCIM automatisch dessen Konto in Salesforce, Slack, GitHub und anderen SCIM-kompatiblen Apps. Wird das Beschäftigungsverhältnis beendet, deaktiviert SCIM alle Konten gleichzeitig – dadurch wird das Zeitfenster geschlossen, in dem verwaiste Konten ausgenutzt werden könnten. SCIM ergänzt SSO-Protokolle (SAML/OIDC), indem es das Lebenszyklusmanagement übernimmt, das von SSO-Protokollen nicht abgedeckt wird.

Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: SAML 2.0 verwendet XML-Assertions für browserbasiertes Enterprise-SSO; OAuth 2.0 ist ein Autorisierungsframework zur Delegation des API-Zugriffs; OpenID Connect ergänzt OAuth um Authentifizierung (JWT-ID-Tokens); und SCIM automatisiert das Identitätslebenszyklusmanagement über föderierte Systeme hinweg. Damit ist der Kurs zu Authentifizierung und Autorisierung abgeschlossen – als Nächstes sehen wir uns die Grundlagen der Netzwerksicherheit an.