SAML vs. OIDC: Was ist der beste Ansatz für Ihr Unternehmen?

Was sind SAML (Security Assertion Markup Language) und OIDC (OpenID Connect)? Beide sind Authentifizierungsprotokolle, die einen Single Sign-On (SSO) ermöglichen. Welches eignet sich besser für Ihr Unternehmen? Wir stellen Ihnen beide Protokolle vor, wie sie arbeiten, was sie auszeichnet und welches für Ihr Unternehmen am besten geeignet ist.

Der Single Sign-On

Was ist ein Single Sign-On und warum ist er wichtig? Jeder Benutzer verwendet tagtäglich viele Apps, Programme und Software. Werden für all diese verschiedenen Dinge Benutzernamen und Passwörter benötigt, gerät die Sache schnell außer Kontrolle. Ein Single Sign-On (SSO) erleichtert Nutzern das Leben erheblich, denn sie müssen sich nur noch an einer Stelle authentifizieren. Benutzernamen- und Passwortdatenbanken werden überflüssig. Mit nur einer ID erhalten Benutzer sicheren Zugriff auf viele Anwendungen und Dienste.

Ein SSO verwendet ein Authentifizierungsprotokoll, das bedeutet vertrauenswürdige, aber unabhängige Systemen tauschen Informationen zu Identitäten aus.

Das Standardprotokoll definiert, wie dieser Austausch stattfindet. SAML und OIDC sind zwei gängige Protokolle für ein erfolgreiches Identity Management. SAML ist die Abkürzung für Security Assertion Markup Language und wird häufig in Arbeitsumgebungen eingesetzt. OIDC kommt beispielsweise zum Einsatz, wenn sich ein Nutzer mit seinem Google-Konto bei einer Anwendung wie YouTube anmeldet.

Was ist SAML?

Dieses Standardprotokoll organisiert die reibungslose Zusammenarbeit der Hauptakteure bei der Authentifizierung. Der Kunde authentifiziert sich an einem Ort, alle Anwendungen werden entsprechend informiert. Die drei Hauptakteure beim Identity Management sind der Benutzer, der Service Provider und der sogenannte Identity Provider. Service Provider sind verschiedene Anwendungen, auf die ein Kunde zugreifen möchte wie Office 365, Webex, Concur und Salesforce. Plant der Kunde beispielsweise Webex zu nutzen, dann fordert Webex, der Service Provider, eine SAML-Authentifizierung an. Der Browser leitet den Kunden mit dieser Anforderung an den Identity Provider weiter. Hier wird sich der Kunde authentifizieren. Dies kann durch Benutzername und Kennwort erfolgen, durch eine Zwei-Faktor-Authentifizierung oder beliebige andere Authentifizierungsmittel oder -mechanismen.

Die Assertion

Sobald der Identity Provider den Kunden als rechtmäßig authentifiziert hat, erstellt er eine sogenannte Assertion. Die Assertion ist ein XML-Dokument. XML ist eine sogenannte Auszeichnungssprache, um Daten strukturiert zu speichern. Die Assertion enthält Informationen über den Kunden und seine Zugriffsrechte. Um die Echtheit der enthaltenen Daten sicherzustellen, ist sie kryptografisch signiert. Diese SAML-Assertion leitet der Browser an den Service Provider weiter – in unserem Beispiel Webex. Dieser überprüft mittels sogenannter Public-Key-Kryptografie die Signatur und der Kunde erhält Zugriff.

Vorteile von Security Assertion Markup Language

Das Protokoll bildet eine externe Struktur innerhalb der Service Provider und Identity Provider Daten zur Authentifizierung und Autorisierung austauschen können. Verschiedene Akteure können den Identitäten des jeweils anderen vertrauen, ohne sensible Informationen preiszugeben. Es ist ein sehr verlässliches und stabiles Protokoll, um die IT-Sicherheit zu garantieren. Insbesondere eignet es sich für Bereiche, in denen viele Identitätsgruppen – Gruppen von Benutzern mit unterschiedlichen Rechten – agieren.

Was ist OIDC?

OpenID Connect kurz OIDC ist ebenfalls ein Standardprotokoll und legt Regeln fest, wenn Unternehmen die Authentifizierung auslagern. Der Ablauf ist folgendermaßen: Der Anwender will auf einen Service Provider zugreifen. Dieser kennt den Anwender nicht und sendet deshalb eine Anfrage an den Identity Provider. Das ist der vertrauenswürdige Dritte, der Nutzer authentifiziert und entsprechende Dokumente ausstellt.

Der Identity Provider schickt ein Dokument mit Claims zurück. Was heißt das? Ein Claim ist eine Behauptung. In unserem Fall kann der Claim der Name des Mitarbeiters sein, seine Rolle im Unternehmen oder die Kontaktdaten. Der Service Provider muss diesem Dokument vertrauen, es muss wahrheitsgemäße Daten enthalten. Dazu wird das Ganze vom Identity Provider mit einem private Key digital signiert. Der Service Provider prüft die Signatur mithilfe eines public Keys oder dem Zertifikat des Identity Providers.

Das Token

Dieses Dokument mit Claims und Signatur ist ein sogenanntes Token. Auch dafür gibt es einen Standard, JWT - JSON Web Token- ein JSON-Objekt mit einer angehängten Signatur. Das ist die digitale Variante eines Personalausweises, den die Bundesdruckerei ausstellt und des Rathauses, das die Identität verifiziert. Das Rathaus fungiert als Identity Provider, will sich der Nutzer ausweisen, wird dem Ausweis vertraut.

Ein JSON Web Token enthält eine ID für den Nutzer in dem Feld Subject, abgekürzt „sub“. Daneben gibt es eine Reihe anderer Felder wie „issued at“ (abgekürzt „iat“) oder „expires at“ (abgekürzt „exp“). Je nach Identity Provider lassen sich im Token weitere Felder hinterlegen, zu viele Felder darf er nicht haben. Der Token wird bei jedem Request mitgeschickt und würde den Datenverkehr zu sehr belasten. All diese Abläufe und Standards entsprechen dem Authentifizerungsprotokoll von OpenID Connect.

Vorteile von OpenID Connect

Token eignen sich gut für hochskalierbare Web- und Cloudanwendungen. Ein Nachteil ist, dass immer eine Umleitung (redirect) erforderlich ist. OpenID Connect funktioniert gut im Webbrowser, jedoch nicht in einer mobilen oder in einer Desktop App. Das gilt jedoch nur für den jetzt beschrieben „Implicit Flow“ von OpenID Connect. Er ist speziell für Single-Page-Anwendungen, also dediziert für den Browser gestaltet. Daneben gibt es andere Flows, beispielsweise den Code Flow oder den Hybrid Flow. Sie funktionieren gut für mobile Apps oder generell für Anwendungen, die keine Single-Page-Applications sind oder nicht im Browser laufen.

Hauptunterschiede zwischen SAML und OIDC

Im Rahmen des Protokolls von OpenID Connect verwenden Benutzer JWT oder JSON Web Token. Damit tauschen verschiedene Dienste Informationen über die Identität aus. Ein JWT ist ein signiertes JSON-Dokument. Bei SAML werden sogenannte Assertions eingesetzt, kryptografisch signierte XML-Dokumente, die Informationen über den Benutzer und seine Rechte enthalten. Das Gesamtkonzept von der beiden Protokolle ist dasselbe. Die Abläufe - die Flows - ähneln sich, die Details bei der Implementierung unterscheiden sich.

Unterschiede in der Implementierung und Nutzung

OCDI ist sehr einfach und ohne neue Infrastruktur zu implementieren, Doch es funktioniert nur für einfache Szenarien. Eine sehr differenzierte Steuerung, eine komplexe Berechtigungsvergabe sind nicht möglich. Das Token wird dann schnell viel zu groß und überlastet den Datenverkehr. Für ein einfaches Szenario, beispielsweise die Frage Administrator oder normaler Anwender, reicht OCDI völlig aus. Plattformen wie Google, Facebook oder GitHub verwenden OCDI. Eine mobile App würde von der Effizienz von OpenID profitieren.

Security Assertion Marking Language ist schwieriger zu implementieren, doch die XML-codierten Assertions erlauben es, viele detaillierte Informationen zu speichern und weiterzugeben. Für Regierungsbehörden oder öffentliche Institutionen, die viele Zugänge kontrollieren und zahlreiche Berechtigungen verwalten, ist es die richtige Lösung. Auch Kliniken, oder Dienstleistern im Gesundheitswesen garantiert es Unternehmenssicherheit durch den kontrollierten Zugriff auf Anwendungsportale oder sensible Daten.

Welches Protokoll ist das richtige für Ihr Unternehmen?

Fazit

Sowohl Security Assertion Markup Language als auch OpenID Connect sind Protokolle für ein erfolgreiches Identity Management. Ihr Einsatz ist keine Frage von Entweder-oder. Je nach Anwendungsfall lassen sich beide, auch in Kombination mit anderen Authentifizierungsstandards, einsetzen. Haben Sie weitere Fragen oder wünschen Sie eine detaillierte Beratung? Rufen Sie an oder schreiben uns. Wir helfen Ihnen gerne weiter.