Single Sign-On (SSO)

• Consumer: "Login with Google". Du musst dir kein neues Passwort für das Forum ausdenken.
• Enterprise: Okta, Active Directory (Azure AD). Der Admin kann mit einem Klick einen Mitarbeiter sperren -> Zugriff auf alle 50 Apps weg. (Sicherheitsgewinn).

1. Protokolle (SAML vs OIDC)

• SAML (Security Assertion Markup Language): XML-basiert. Der alte Enterprise-Standard (seit 2005). Mächtig, aber komplex und verbos.
• OIDC (OpenID Connect): JSON-basiert (auf OAuth 2.0). Modern, Mobile-freundlich. "Login with Google" ist OIDC. ID-Token (JWT) enthält User-Infos.

2. Der Anmelde-Flow (SP-Initiated)

1. User geht zu Slack (Service Provider, SP).
2. Slack sieht "Nicht eingeloggt". Leitet User zu Okta (Identity Provider, IdP).
3. User loggt sich bei Okta ein.
4. Okta schickt User zurück zu Slack mit einem "Ticket" (Token/Assertion).
5. Slack prüft Ticket (Signatur). Loggt User ein.

SAML (Der XML Trust-Dance)

Security Assertion Markup Language (SAML 2.0) basiert auf kryptografisch bewiesenen XML-Dokumenten (Assertions). Der kritischste Punkt: Wie weiß Slack (SP), dass das empfangene XML von Okta (IdP) kommt und nicht von einem Angreifer unterschoben wurde? Der Identity Provider signiert den <Assertion>-Block asymmetrisch per X.509 RSA Private Key. Slack hält den Public Key von Okta (wird beim Initial-Setup des SSO via Metadata-XML ausgetauscht). Slack validiert die Signatur. Ein katastrophaler, klassischer Bug in SP-Libraries war "XML Signature Wrapping" (XSW). Der Parser validierte die Signatur im originalen Element, extrahierte aber die User-ID für den Login-Context aus einem vom Hacker injizierten, un-signierten Kopie-Element tief unten im XML-Baum. So loggte man sich als Admin in Fremd-Accounts ein.

OIDC vs. OAuth 2.0 (Identity vs. Authority)

Entwickler verwechseln das ständig: OAuth 2.0 ist kein Authentifizierungs-Protokoll! Es ist reine Autorisierung (Delegation). Es sagt: "App X darf Namen im Namen von User Y auslesen." (Access Token). Das Access Token ist oft opak (eine reine ID-Wurst) und bringt keine User-Identität mit sich. OpenID Connect (OIDC) legt eine dünne Identitäts-Ebene über OAuth 2.0. OIDC verlangt den Scope openid. Das Resultat: Die App erhält zusätzlich ein ID-Token im JWT-Format (JSON Web Token). Wenn das Frontend dieses JWT decodiert, sieht es sofort: {"name": "Max", "email": "[email protected]"}. OIDC standardisiert SSO für moderne REST-Apps endgültig.

IdP MFA-Bypass (Das Sessions-Limit)

Ein tückisches Architektur-Risiko bei SSO: User loggt sich bei Azure AD (IdP) ein, Azure verlangt streng den Hardware-Token (MFA/Yubikey) – perfekt. Er erhält SSO-Zugang zur Cloud-App. Nun klaut ein Hacker den Session Cookie der Cloud-App (die den User bereits als validiert ansieht). Der Hacker surft mit der Cookie-Session, die App lässt ihn ein. Die MFA beim IdP nutzt dem Unternehmen hier exakt gar nichts, da der IdP nach dem Initial-Prozess (Token Handover) im laufenden Traffic völlig blind ist! Lösungen: Continuous Access Evaluation (CAE). Die Cloud-App pollt im Hintergrund den IdP ("Ist der Status des Users noch safe? Hat sich seine IP ins Ausland verlagert?"), um im Zweifel den SP-Session-Cookie sofort brutal terminieren zu können und eine Re-Authentication zu forcieren.