artikel
OpenID Connect (OIDC) ist ein offenes Authentifizierungsprotokoll, das OAuth 2.0 profiliert und um eine zusätzliche Identitätsebene erweitert. Über OIDC können Clients die Identität eines Endnutzers mit Hilfe der Authentifizierung durch einen Autorisierungsserver bestätigen. Das Einbinden von OIDC in Ergänzung von OAuth 2.0 schafft ein einzelnes Framework, das die Sicherung von APIs, mobilen nativen Anwendungen wie auch Browser-Anwendungen in einer einzigen kohärenten Architektur verspricht.
OAuth 2.0 ist ein Autorisierungs-Framework. Es delegiert die Benutzerauthentifizierung an den Dienstanbieter, der das Nutzerkonto hostet, und Anwendungen von Drittanbietern für den Zugriff auf das Nutzerkonto autorisiert. OAuth 2.0 stellt Autorisierungsabläufe für Webanwendungen, Desktopanwendungen und mobile Geräte bereit.
Durch die Einführung einer Autorisierungsschicht trennt OAuth 2.0 die Rollen der Clients von den Ressourceneigentümern bzw. Endnutzern. Wenn der Client Zugriff auf Ressourcen verlangt, die vom Endnutzer kontrolliert und vom Ressourcenserver gehostet werden, erhält der Client für den Zugriff auf geschützte Ressourcen ein Zugriffs-Token und meldet sich nicht mit den Anmeldedaten des Endnutzers an. Mit der Zustimmung des Endnutzers stellt der Autorisierungsserver dem anfragenden Client das Zugangs-Token aus.
OAuth 2.0 dient im Speziellen der Unterstützung einer Vielzahl verschiedener Client-Typen, die auf REST-APIs zugreifen. Dazu gehören unter anderem Anwendungen, die auf unternehmenseigenen Webservern laufen und mit der Cloud kommunizieren, sowie solche auf den Mobilgeräten von Mitarbeitern und Kunden. Das OAuth-Framework unterstützt verschiedenste dieser Client-Typen, indem mehrere Mechanismen zum Erhalt eines Tokens definiert werden, wobei diese die Einschränkungen des Client-Typs erkennen.
Der Hauptunterschied zwischen OpenID und OAuth besteht darin, dass OpenID ein Authentifizierungsprotokoll und OAuth ein Autorisierungs-Framework ist. OpenID und OAuth sind beides offene Standards, die sich gegenseitig ergänzen, aber OpenID ermöglicht die Authentifizierung von Nutzern durch Relying Parties. Eine OIDC-Relying Party ist eine OAuth 2.0-Client-Anwendung, welche die Authentifizierung eines Benutzers und die Anfrage eines OIDC-Anbieters benötigt. OAuth ermöglicht das Ausstellen von Zugriffs-Token für Drittanbieter-Clients über einen Autorisierungsserver. OpenID Connect wurde auf der Basis eines OAuth-Profils entwickelt und bietet zusätzliche Funktionen zur Übertragung der Identität des Nutzers einer Anwendung. Clients verwenden OAuth, um im Namen eines Nutzers Zugriff für eine API anzufordern, wobei das OAuth-Protokoll dem Client in keiner Form Benutzerinformationen übermittelt. OpenID Connect ermöglicht einem Client den Zugang zu zusätzlichen Informationen über einen Nutzer, wie beispielsweise den echten Namen des Nutzers, seine E-Mail-Adresse, sein Geburtsdatum oder andere Profildaten.
OpenID Connect und SAML sind beides Identitätsprotokolle zur Authentifizierung von Nutzern, die Identitätsdaten für die Zugriffskontrolle liefern. Ein wesentlicher Unterschied zwischen OpenID Connect und SAML ist das Ausmaß der Kommunikation zwischen der Anwendung und dem Identitätsanbieter.
SAML verwendet in XML geschriebene SAML-Token. Die Anwendung validiert die Signatur selbst sowie das vorgelegte Zertifikat. Während SAML auf eher schweren XML-Nutzdaten beruht, ist OpenID Connect REST/JSON-basiert. OpenID Connect-Anbieter stellen sowohl ein Zugriffs-Token als auch ein ID-Token aus. OpenID Connect ermöglicht es einer Anwendung, die Identität zu erhalten, ohne dass ein Aufruf der Anwendung an den Identitätsanbieter erforderlich ist.
Die Anwendung beginnt mit einem OAuth-Fluss, der den Nutzer zur Autorisierung einer Anfrage auffordert. Im Zuge dieses Flusses schließt der Client den OpenID Connect-Bereich gemeinsam mit Bereichen für jede zusätzliche Benutzerinformation ein, die er benötigt.
Nach der Verarbeitung der Anfrage erhält der Client ein Zugriffs-Token und ein ID-Token, die von dem Autorisierungsserver ausgestellt werden, der Anfragen mit Daten dieses Nutzers enthält. Die SSO-Erfahrung des Nutzers basiert auf der Übermittlung des ID-Tokens vom Autorisierungsserver an den Client. Der Client kann anschließend einen speziellen Endpunkt auf dem Autorisierungsserver ansprechen, der auch als UserInfo-Endpunkt bezeichnet wird, um dort die übrigen Anfragen über den Nutzer abzurufen.
OpenID Connect definiert auch Mechanismen für das Erkennungs- und Sitzungsmanagement, die über OAuth hinausgehen.
OpenID Connect ist ein offenes und vertrauenswürdiges Authentifizierungsprotokoll, mit dem sich Nutzer bei einem externen vertrauenswürdigen Identitätsanbieter authentifizieren können. OpenID Connect ergänzt das OAuth 2.0-Framework. Dabei ist es wichtig zu wissen, dass OAuth 2.0 kein Identitätsprotokoll ist, sondern ein Authentifizierungs- und Autorisierungs-Framework für die Absicherung beliebiger APIs im Gegensatz zu APIs, die Identitätsinformationen schützen. Darüber hinaus haben die Zugriffs-Token von OAuth zwar eine Autorisierungssemantik, aber keine Identitätssemantik. OpenID Connect schichtet diese beiden identitätsbasierten Konzepte auf das OAuth, um ein Framework für verteilte Identitäten zu schaffen.
OpenID 1.0 wurde 2006 als erster Mainstream-Standard für die Authentifizierung veröffentlicht. Im Jahr 2007 kam OpenID 2.0 heraus, das sowohl Benutzerauthentifizierung als auch Benutzerattribute bereitstellte. OpenID 2.0 fand weite Verbreitung und wurde von den meisten großen Internetunternehmen unterstützt. Erst 2014 wurde OpenID Connect veröffentlicht und machte die vorangegangenen Versionen überflüssig. OpenID Connect bietet die gleichen Funktionen wie OpenID 2.0, bleibt aber bei der Erfüllung seiner Aufgaben API-freundlich und zugänglich für native und mobile Anwendungen. OpenID Connect verfügt auch über optionale Mechanismen für die Signierung und Verschlüsselung. Für das Einbinden von OAuth 1.0a und OpenID 2.0 war eine Erweiterung erforderlich, aber mit OpenID Connect werden die OAuth 2.0-Funktionen einfach in das Protokoll integriert. Wenn von „OpenID“ gesprochen wird, ist zumeist OpenID Connect gemeint.
Im OAuth 2.0 Leitfaden für Entwickler von Ping Identity finden Sie einen Überblick über die Prozesse, die ein Anwendungsentwickler und ein API-Entwickler bei der Implementierung des OAuth 2.0-Protokolls berücksichtigen müssen.
Ist OAuth besser als SAML?OAuth und SAML sind keine austauschbaren Standards, sondern greifen vielmehr ineinander, um eine robuste Authentifizierungs- und Autorisierungslösung zu erschaffen. OAuth ist das Autorisierungsverfahren und SAML ist das Authentifizierungsverfahren. | ||
Ist OpenID Connect besser als SAML?Da SAML ein intensives XML-Handling benötigt, bevorzugen Entwickler in der Regel die flexiblere und einfachere Verwendung von OpenID Connect. Im Allgemeinen unterstützen Anwendungen entweder SAML oder OIDC, daher hängt es davon ab, welches Identitätsprotokoll sich für Ihre Anwendung besser eignet.
Bei Ping Identity können Sie ein Whitepaper mit weiteren Informationen über SAML herunterladen. | ||
Wie funktioniert SSO mit OpenID Connect?Bei den Produkten von Ping Identity wird das OpenID Connect-SSO durch Ergänzung der folgenden einfachen Konfigurationen aktiviert:
PingFederate: https://docs.pingidentity.com/bundle/MyPing/page/awz1604962098131.html
PingAccess: https://docs.pingidentity.com/bundle/MyPing/page/qjq1605722295704.html
PingOne: https://docs.pingidentity.com/bundle/pingintelligence-44/page/dqe1616546061657.html
PingCentral: https://docs.pingidentity.com/bundle/pingcentral-18/page/qyh1624306876538.html
PingDirectory: https://docs.pingidentity.com/bundle/MyPing/page/pxy1607014262073.html | ||
Wie kann ich OAuth anfordern?Bei der OAuth-Autorisierungsanfrage leiten Clients den Browser eines Benutzers an den Autorisierungsserver weiter, um den OAuth-Prozess zu starten. Clients können einen Autorisierungs-Code oder die implizite Erlaubnis verwenden. Neben der Art von Erlaubnis, die durch den Parameter „response_type“ spezifiziert wird, hat die Anfrage eine Reihe von weiteren Parametern, um die Besonderheiten der Anfrage anzugeben. | ||
Was beinhaltet ein OAuth-Dienst?OAuth 2.0 ist ein Autorisierungs-Framework. Es delegiert die Benutzerauthentifizierung an den Dienstanbieter, der das Benutzerkonto hostet, und Anwendungen von Drittanbietern für den Zugriff darauf autorisiert. OAuth 2.0 stellt Autorisierungsabläufe für Webanwendungen, Desktopanwendungen und mobile Geräte bereit. | ||
Fallbeispiele für OAuth?Viele Kontoanbieter verwenden OAuth. Wenn Sie beispielsweise auf einer Website aufgefordert werden, sich bei Google, Facebook, Twitter oder LinkedIn anzumelden, verwendet dieser Prozess OAuth. Grundsätzlich überlässt OAuth es Ihnen, ob eine Website auf relevante Informationen zu Ihrem Konto zugreifen darf, ohne dass Ihr Passwort weitergegeben wird. | ||
Wie wird die Authentifizierung mit OAuth eingerichtet?Im OAuth 2.0 Leitfaden für Entwickler von Ping Identity finden Sie einen Überblick über die Prozesse, die Anwendungsentwickler und API-Entwickler bei der Implementierung des OAuth 2.0-Protokolls berücksichtigen müssen. |
Weitere Informationen darüber, wie OpenID Connect Identitätsdaten in einem zunehmend komplexen Ökosystem sichern kann, finden Sie in unserem Ping Identity Whitepaper OpenID Connect 101.
Starten Sie jetzt
Erfahren Sie, wie Ping Sie dabei unterstützen kann, sichere Mitarbeiter- und Kundenerlebnisse in einer sich schnell entwickelnden digitalen Welt zu schaffen.
Kostenlose Demo anfordern
Vielen Dank! Behalten Sie Ihren Posteingang im Auge. Wir melden uns bald bei Ihnen.S