Was ist OAuth (Open Authorization)?

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.

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.

Durch die Vereinfachung des sicheren Zugriffs kann OAuth Unternehmen dabei helfen, einige ihrer größten Sicherheitsherausforderungen zu bewältigen. Eine Studie des IBM Institute for Business Value ergab beispielsweise, dass 52 % der Führungskräfte die Komplexität als größtes Hindernis für ihre Cybersicherheitsmaßnahmen bezeichnen.

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

Hier ist ein grundlegender Überblick darüber, wie ein OAuth-Flow funktionieren könnte:

1. Jim (der Ressourceneigentümer) möchte einer Website für Social Media (dem Client) den Zugriff auf seine E-Mail-Kontakte (die Ressource) erlauben.
   
   
2. Der E-Mail-Autorisierungsserver fordert Jim auf, die Zustimmung für diesen Zugriff zu erteilen.
   
   
3. Nachdem er Jims Zustimmung erhalten hat, stellt der Autorisierungsserver der Social Media-Website ein Zugriffstoken zur Verfügung.
   
   
4. Die Social-Media-Website stellt das Zugriffstoken für den Ressourcenserver bereit, auf dem Jims E-Mail-Kontoinformationen gespeichert sind.
   
   
5. 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.Zum Beispiel ermöglicht ein Client Credentials Grant einer Wetter-App den Zugriff auf eine API, um Daten zur aktuellsten 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 nutzt häufig einen Identitätsanbieter (IdP) und die Security Assertion Markup Language (SAML), die auf Extensible Markup Language (XML) basiert, um die digitalen Identitäten von Nutzern über 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. Zusammenarbeit OpenID Connect kann die Identität eines Benutzers überprüfen und anschließend OAuth den Benutzer für den Zugriff auf Ressourcen und Dienste autorisieren.