Identity Management: SAML vs. OAuth2 vs. OpenID Connect

Angefangen hat alles damit, dass Organisationen eine Möglichkeit brauchten, ihre Authentifizierungssysteme für eine bessere Verwaltung und Sicherheit zu zentralisieren. An dieser Stelle kam Single Sign On (SSO) ins Spiel. Single Sign On (SSO) ist ein zentralisierter Sitzungs- und Benutzerauthentifizierungsdienst, bei dem ein Satz von Anmeldedaten für den Zugriff auf mehrere Anwendungen verwendet werden kann. Seine Schönheit liegt in der Einfachheit: Der Dienst authentifiziert Sie auf einer Plattform und ermöglicht es Ihnen, sich transparent bei mehreren internen Diensten anzumelden, ohne sich jedes Mal an- und abmelden zu müssen.

Als Nächstes kamen App-Entwickler von Drittanbietern, die die internen APIs nutzen wollten, um sie in ihre Produkte und Lösungen zu integrieren, dies war eindeutig eine Herausforderung. Dann kamen die sozialen Netzwerke und machten die Sache noch komplizierter. Derzeit gibt es Tausende von Apps, die die Authentifizierung über soziale Netzwerke wie Facebook, Google, Twitter, LinkedIn usw. unterstützen. Das Problem bei diesen Architekturen ist die Herausforderung, die Dinge so einfach wie möglich zu halten und gleichzeitig die Sicherheit zu erhöhen. Die Lösung? Federated Identities.

Zurzeit sind die drei wichtigsten Protokolle für föderierte Identitäten: SAML, OAuth2 & OpenID Connect. Bevor wir in die Tiefe dieser drei Protokolle eintauchen, lassen Sie uns einige gängige Konzepte besprechen, die Menschen dazu neigen, zu verwechseln.

Wenn es um Sicherheit und Zugriff geht, sind Authentifizierung & und Autorisierung zwei Begriffe, die Menschen dazu neigen, zu übersehen, und die oft fälschlicherweise das Gleiche bedeuten. Nun, Authentifizierung ist die Überprüfung Ihrer Identität, während Autorisierung die Überprüfung dessen ist, worauf Sie Zugriff haben.

Authentifizierung ist die Überprüfung der Anmeldedaten, bevor der Benutzer Zugriff auf das System erhält. Wenn es um Sicherheit geht, wird empfohlen, mindestens zwei Authentifizierungsfaktoren zu verwenden, bevor dem Benutzer der Zugriff auf etwas gewährt wird. (2FA, MFA, digitale & physische Token, usw.).

Die Autorisierung erfolgt nach dem Authentifizierungsprozess, indem Ihre Rechte überprüft werden, bevor Ihnen der Zugriff auf die benötigten Ressourcen wie Datenbanken, Dateien, Repositories, etc. Ein praktisches Beispiel wäre, nachdem die Logins eines Mitarbeiters verifiziert wurden, zu sehen, auf welche Stockwerke er Zugriff hat.

Beide, die Autorisierung & und die Authentifizierung, sind für die Sicherheits- und Zugriffsverwaltung von entscheidender Bedeutung, und obwohl hinter beiden unterschiedliche Konzepte stehen, sind sie für die Infrastruktur eines Systems von entscheidender Bedeutung, und ihr Verständnis ist der Schlüssel für die Identitäts- und Zugriffsverwaltung.

SAML

Security Assertion Markup Language (SAML) ist ein XML-basierter offener Standard, der für Single Sign On (SSO) Implementierungen verwendet wird. SAML 2.0 wurde 2005 veröffentlicht und ist die aktuelle Version des Standards.

SAML wird sowohl für die Authentifizierung & als auch für die Autorisierung zwischen zwei Parteien verwendet: einem Service Provider (Office365, Salesforce, G Suite, etc.) & und einem Identity Provider (Okta, OneLogin, Ping Identity, etc.). Der Service Provider (SP) stimmt zu, dem Identity Provider (IdP) im Authentifizierungsprozess zu vertrauen. Dies geschieht durch ein SAML-XML-Dokument, das vom IdP gesendet wird und die &Authentifizierung des Benutzers enthält und dann an den Dienstanbieter weitergeleitet wird.

Betrachten wir dieses Beispiel:

• Identity Provider (IdP): Okta
• Service Provider (SP): Salesforce-Anwendung

1. Benutzer versucht, sich über Chrome bei der Salesforce-Anwendung seines Unternehmens anzumelden.
2. Die Salesforce-Anwendung antwortet, indem sie eine SAML-Anfrage generiert
3. Chrome leitet den Benutzer zu einer SSO-URL um, Okta analysiert die SAML-Anfrage, authentifiziert den Benutzer (dies kann über Benutzername und Passwort, Zwei-Faktor-Authentifizierung oder MFA erfolgen, wenn sich der Benutzer nicht im internen Netzwerk des Unternehmens befindet; wenn der Benutzer bereits auf Okta authentifiziert ist, wird dieser Schritt übersprungen) und generiert eine SAML-Antwort.
4. Okta sendet die verschlüsselte SAML-Antwort erneut an Chrome
5. Chrome leitet die SAML-Antwort an die Salesforce-Anwendung weiter
6. Wenn die Verifizierung erfolgreich ist, wird der Benutzer in der Salesforce-Anwendung angemeldet und erhält Zugriff auf alle verschiedenen Ressourcen.

OAuth2

„Wie kann ich einer App den Zugriff auf meine Daten erlauben, ohne ihr notwendigerweise mein Passwort zu geben?“

OAuth2 ist ein offener Standard, der für die Autorisierung verwendet wird und es Apps ermöglicht, eine „delegierte Autorisierung“ bereitzustellen. Im Gegensatz zu anderen Frameworks, die eine Authentifizierung bieten, autorisiert OAuth nur Geräte, APIs und Server mit Zugriffstoken anstatt mit Anmeldeinformationen und es funktioniert über HTTPS.

Wenn Sie jemals einen der untenstehenden Dialoge gesehen haben, ist das genau das, worüber wir sprechen. Das ist eine Anwendung, die fragt, ob sie in Ihrem Namen auf Daten zugreifen darf. Das ist OAuth.

Sie können sich das wie Hotelschlüsselkarten vorstellen, aber für Apps. Wenn Sie eine Hotel-Schlüsselkarte haben, können Sie sich Zugang zu Ihrem Zimmer verschaffen. Wie bekommt man eine Hotel-Schlüsselkarte? Sie müssen einen Authentifizierungsprozess an der Rezeption durchführen, um sie zu erhalten. Nachdem Sie sich authentifiziert und die Schlüsselkarte erhalten haben, können Sie auf Ressourcen im gesamten Hotel zugreifen.

OAuth definiert vier Rollen:

• Ressourcenbesitzer: In der Regel der Benutzer selbst
• Client: Anwendung, die Zugriff auf einen Ressourcen-Server anfordert
• Ressourcen-Server: Server, der geschützte Daten hostet (zum Beispiel Facebook, das Ihr Profil und Ihre persönlichen Informationen hostet)
• Autorisierungsserver: Server, der dem Client ein Zugriffstoken ausstellt. Dieses Token wird für den Client verwendet, um den Ressourcenserver anzufordern.

Unten ist ein Diagramm des OAuth2-Flusses.

Betrachten wir dieses Beispiel:

1. Spotify möchte auf Ihre Freundesliste aus Ihrem Facebook-Konto zugreifen.
2. Sie werden von Spotify an den Autorisierungsserver (in diesem Fall Facebook) weitergeleitet.
3. Wenn Sie den Zugriff autorisieren, sendet der Autorisierungsserver in der Callback-Antwort einen Autorisierungscode an den Client (Spotify).
4. Dieser Code wird dann zwischen Facebook und Spotify gegen ein Access-Token ausgetauscht.
5. Nun ist Spotify in der Lage, dieses Zugriffstoken zu verwenden, um den Ressourcenserver (Facebook) abzufragen und Ihre Freundesliste abzurufen.

Eine Sache, die zu beachten ist, ist, dass der Benutzer das Zugriffstoken nie zu sehen bekommt, es wird in der Sitzung gespeichert. Der Autorisierungsserver sendet auch andere Informationen wie die Token-Lebensdauer und ein Refresh-Token.

OpenID Connect

OpenID Connect ist eine einfache Identitätsschicht über dem OAuth 2.0-Protokoll, die OAuth2 erweitert und eine „Federated Authentication“ ermöglicht.

Der Prozessablauf von OpenID Connect ähnelt dem OAuth2-Autorisierungsablauf mit dem Hauptunterschied, dass ein ‚id-token‘ die Benutzerauthentifizierung ermöglicht.

Beachten Sie, dass Federated Authentication etwas völlig anderes ist als Delegated Authorization. Nehmen wir wieder das Beispiel von Facebook und Spotify

• Federated Authentication ist die Anmeldung bei Spotify mit Ihren Facebook-Anmeldedaten.
• Delegated Authorization ist die Fähigkeit einer externen App, auf Ressourcen zuzugreifen. In diesem Fall versucht Spotify, auf Ihre Facebook-Freundesliste zuzugreifen, um sie in Spotify zu importieren.

Zum Abschluss gibt es hier eine Tabelle, die alle drei Protokolle/Frameworks zusammenfasst.