Published: 29. Juli 2024
Mitwirkende: Gregg Lindemulder, Matt Kosinski
Open Authorization (OAuth) ist ein Autorisierungs-Framework nach offenem Standard, das Anwendungen Zugriff auf die geschützten Ressourcen eines Endbenutzers gewährt – wie z. B. seine Fotos, Kalender oder Social-Media-Posts –, ohne dass ein Login oder Passwort für das Benutzerkonto erforderlich ist.
Websites und Anwendungen von Drittanbietern, die Nutzer auffordern, sich mit Google anzumelden oder „Zugriff auf Ihre Kontoinformationen erlauben?“ sind häufige Anwendungsfälle für OAuth. Das OAuth-Protokoll ermöglicht es Benutzern, diesen Anwendungen auf einfache Weise Zugriff auf ihre Kontodaten zu gewähren, ohne ihre Benutzeranmeldeinformationen weitergeben zu müssen.
Neben Webanwendungen kann OAuth auch den Zugriff auf Ressourcen für APIs, serverseitige Anwendungen, native Betriebssystem-Apps, mobile Apps und Geräte wie Smart TVs und Geräte gewähren. In einigen Fällen ist kein menschlicher Benutzer involviert, da OAuth den Anwendungszugriff im Namen eines Unternehmens oder eines Geschäftskontos autorisieren kann.
Erfahren Sie, warum IBM® laut KuppingerCole ein führender Anbieter von ausgereiften, skalierbaren und sicheren Authentifizierungslösungen für Unternehmen ist.
OAuth bietet Nutzern, Entwicklern und Unternehmen wichtige Vorteile bei der Zugriffsverwaltung, da Anmeldedaten unzugänglich bleiben und der Zugriff auf andere sensible Informationen eingeschränkt wird. Außerdem können Anwendungen leichter auf die erforderlichen Kontoinformationen zugreifen, ohne die Sicherheitslücken, die die gemeinsame Nutzung von Benutzeranmeldeinformationen mit sich bringt.
Ein kleines Team von Softwareentwicklern veröffentlichte OAuth 1.0 im Jahr 2007. Diese erste Version des Protokolls wurde als Alternative zur webbasierten Authentifizierung entwickelt, bei der die Benutzer ihre Benutzernamen und Passwörter an Dienste Dritter weitergeben mussten. OAuth 1.0 bot jedoch nur Berechtigungsabläufe für Websites.
Im Jahr 2012 veröffentlichte die Internet Engineering Task Force (IETF) OAuth 2.0 als RFC 6749 und RFC 6750. Ein RFC (Request for Comments) ist ein IETF-Dokument, das Internet-Kommunikationsprotokolle beschreibt. RFC 6749 ist das Kerngerüst für OAuth 2.0, und RFC 6750 definiert, wie das Gerüst Zugriffstoken verwendet.
Diese aktualisierte Version von OAuth erweitert das Protokoll über Webbrowser hinaus auf Autorisierungsfunktionen für Anwendungen, APIs und Geräte. OAuth 2.0 hat OAuth 1.0 ersetzt und ist jetzt der Branchenstandard.
Im Gegensatz zu anderen Frameworks, die auf Benutzernamen und Passwörtern beruhen, ist OAuth ein Autorisierungsprotokoll, das auf Zugriffstokens basiert. Zugriffstoken sind Informationen, die bestimmen, auf welche Ressourcen eine Anwendung zugreifen darf. Das OAuth-Protokoll definiert, wie jede Komponente in einem Autorisierungsanfrageprozess Zugriffstoken genehmigt, definiert und verwaltet.
OAuth-Tokens verwenden in der Regel den Standard JSON Web Token (JWT), da dieser eine sichere Datenübertragung ermöglicht.
Die wichtigsten Komponenten des OAuth-Frameworks sind:
- Ressourceneigentümer
- Ressourcenserver
- Kunde
- Autorisierungsserver
- Bewerten
Dies ist der Endbenutzer, dem das Konto gehört, auf das die Anwendung zugreifen möchte, z. B. ein Facebook- oder Google-Konto. Der Eigentümer der Ressource erteilt der Anwendung die Erlaubnis, auf bestimmte geschützte Ressourcen in diesem Konto zuzugreifen, z. B. auf Fotos oder personenbezogene Daten. In einigen Fällen kann der Eigentümer der Ressource ein Unternehmens- oder ein Geschäftskonto sein.
Dies ist der Server, der die geschützten Ressourcen im Namen des Benutzers speichert. Der Ressourcenserver akzeptiert und validiert die OAuth-Tokens, die er vom Client erhält, und stellt dann die Benutzerdaten bereit, deren Freigabe der Eigentümer der Ressource zugestimmt hat.
Der Client ist die Anwendung, Website, API oder das Gerät, das den Zugriff anfordert. Er fordert eine Autorisierung vom Autorisierungsserver an, indem er eine Client-ID angibt. Nachdem der Ressourceneigentümer seine Zustimmung erteilt hat, erhält der Client ein Zugriffstoken, mit dem er auf geschützte Ressourcen auf dem Ressourcenserver zugreifen kann.
Dies ist der primäre Server, der das OAuth-Protokoll steuert. Er bedient zwei Endpunkte, um den Zugriff auf den Ressourcenserver zu gewähren.
Das Autorisierungsendgerät fordert den Eigentümer der Ressource auf, seine Zustimmung für bestimmte geschützte Ressourcen zu erteilen. Der Token-Endpunkt erhält dann die Token-Anforderung vom OAuth-Client und generiert neue Zugriffstoken, die Zugriff auf die Ressourcen gewähren.
Scopes sind die Zugriffsparameter für geschützte Ressourcen auf dem Ressourcenserver.
Zum Beispiel kann der Eigentümer der Ressource gebeten werden, seine Zustimmung zum Zugriff auf Daten wie E-Mails, Dateien oder Fotos zu geben. Der Scope schränkt den Zugriff des Clients auf diese Objekte ein.
Hier ist ein grundlegender Überblick darüber, wie ein OAuth-Flow funktionieren könnte:
- Jim (der Ressourceneigentümer) möchte einer Website für Social Media (dem Client) den Zugriff auf seine E-Mail-Kontakte (die Ressource) erlauben.
- Der E-Mail-Autorisierungsserver fordert Jim auf, die Zustimmung für diesen Zugriff zu erteilen.
- Nachdem er Jims Zustimmung erhalten hat, stellt der Autorisierungsserver der Social Media-Website ein Zugriffstoken zur Verfügung.
- Die Social-Media-Website stellt das Zugriffstoken für den Ressourcenserver bereit, auf dem Jims E-Mail-Kontoinformationen gespeichert sind.
- Der Ressourcenserver erkennt das Zugriffstoken und gewährt der Social-Media-Site Zugriff auf die E-Mail-Kontakte von Jim. Da das Zugriffstoken den Scope von Jims Zustimmung enthält, kann die Social Media-Website nicht auf andere Daten von Jims Konto zugreifen.
Das Verfahren zur Bereitstellung eines Zugriffstokens für eine Anwendung wird als Autorisierungsberechtigung (Authorization Grant) oder Autorisierungsablauf (Authorization Flow) bezeichnet. Es gibt verschiedene Arten von Berechtigungen und OAuth-Flows, die für verschiedene Arten von Anwendungen, Geräten oder APIs verwendet werden können, z. B:
- Autorisierungscode
- Nachweisschlüssel für Code-Austausch (Proof Key for Code Exchange, PKCE)
- Anmeldedaten des Kunden
- Implizite Berechtigung
- Aktualisierungstoken
Dieser Berechtigungstyp wird normalerweise für Webanwendungen und mobile Apps verwendet. In einem Autorisierungscode-Flow stellt der Autorisierungsserver dem Client einen einmaligen Autorisierungscode zur Verfügung. Der Client kann dann diesen Autorisierungscode über das Token-Endgerät des Autorisierungsservers gegen ein Zugriffstoken austauschen.
Dieser Flow fügt der Autorisierungscode-Erteilung zusätzliche Sicherheit hinzu, um Anwendungen vor Code-Injection-Angriffen zu schützen. Diese Art von Angriffen kann Apps dazu verleiten, bösartigen Code auszuführen, der ihre Funktionsweise verändert.
PKCE fügt ein „Client-Geheimnis“ hinzu, das den Client gegenüber dem Autorisierungsserver authentifiziert, bevor ein Zugriffstoken ausgestellt wird. Da nur der legitime Kunde das Geheimnis kennt, können böswillige Akteure nicht vorgeben, der Kunde zu sein und bösartigen Code einschleusen.
Diese Berechtigungsart ist für Situationen gedacht, in denen kein menschlicher Benutzer involviert ist, wie z. B. bei automatisierten Prozessen, Maschine-zu-Maschine-Interaktionen und Microservices.
Anwendungen erhalten Zugriff auf Systemressourcen, die sie für die Ausführung von Funktionen benötigen, erhalten jedoch keinen Zugriff auf Endbenutzerressourcen. Ein Client Credentials Grant zur Erteilung von Berechtigungsnachweisen für Kunden könnte zum Beispiel einer Wetter-App den Zugriff auf eine API ermöglichen, um Daten zur aktuellen Wettervorhersage abzurufen.
Diese Art der Berechtigung bietet einen einfacheren Ablauf für JavaScript-Webanwendungen. Im Gegensatz zur Gewährung des Autorisierungscodes ist für den impliziten Ablauf kein Autorisierungscode erforderlich, bevor ein Zugriffstoken ausgestellt wird.
Stattdessen wird das Zugriffstoken, nachdem der Benutzer seine Zustimmung gegeben hat, in den umgeleiteten Uniform Resource Identifier (URI) aufgenommen, der den Benutzer an die Anwendung zurückleitet, die den Zugriff anfordert. Die Anwendung erhält das Zugriffstoken aus dem URI.
Wenn ein Zugriffstoken abgelaufen ist, stellt diese Berechtigungsart der Anwendung ein Refresh-Token zur Verfügung, das gegen ein neues Zugriffstoken ausgetauscht werden kann. Ohne ein Aktualisierungs-Token müsste der Endbenutzer erneut seine Zustimmung geben, damit die Anwendung ein neues Zugriffstoken erhält.
Der wesentliche Unterschied besteht darin, dass Single Sign-on (SSO) ein Benutzerauthentifizierungsprotokoll ist und OAuth ein Autorisierungsprotokoll ist.
SSO verwendet häufig einen Identitätsanbieter (IdP) und die Security Assertion Markup Language (SAML), die auf der Extensible Markup Language (XML) basiert, um die digitalen Identitäten von Benutzern durch Benutzernamen und Passwörter zu authentifizieren.
OAuth authentifiziert Benutzer nicht, autorisiert sie jedoch für den Zugriff auf Systemressourcen. SSO-Lösungen verwenden manchmal OAuth, um authentifizierten Benutzern einen einfachen Zugriff auf Anwendungen und Services im gesamten Unternehmen zu ermöglichen.
OpenID Connect (OIDC) ist ein Authentifizierungsprotokoll, das auf OAuth 2.0 basiert. Im Zusammenspiel kann OpenID Connect die Identität eines Benutzers verifizieren und dann kann OAuth diesen Benutzer für den Zugriff auf Ressourcen und Services autorisieren.
Schützen und verwalten Sie Kunden-, Mitarbeiter- und privilegierte Identitäten in der Hybrid Cloud mit Hilfe von KI.
Fügen Sie dem Benutzerzugriff auf Ihre Daten und Anwendungen tiefgreifenden Kontext, Intelligenz und Sicherheit hinzu.
Sichern, kontrollieren und vermitteln Sie den Zugriff auf Ihre APIs, um sie vor zunehmenden Bedrohungen zu schützen.
Erhalten Sie wichtige Erkenntnisse, die Ihren Sicherheits- und IT-Teams dabei helfen, Risiken und potenzielle Verluste besser zu managen.
Machen Sie sich mit den neuesten Cyberangriffstaktiken vertraut, um Ihre Mitarbeiter, Daten und Infrastruktur besser zu schützen.
In einem Computersystem ist die Authentifizierung (kurz „auth“) der Prozess, der überprüft, ob ein Benutzer derjenige ist, für den er sich ausgibt.