Einführung in OAuth 2.0

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

OAuth-Startseite: Auf der OAuth-Startseite finden Sie eine Übersicht über die von uns bereitgestellte OAuth-Anleitung.

Dieses Thema bietet eine grundlegende Übersicht über OAuth 2.0 in Apigee.

Was ist OAuth 2.0?

Es gibt viele Bücher, Blogs und Websites zu OAuth 2.0. Es wird dringend empfohlen, zuerst die IETF OAuth 2.0-Spezifikation zu lesen. Nachstehend sehen Sie die Definition von OAuth 2.0 in der OAuth 2.0 IETF-Spezifikation:

„Das OAuth 2.0-Autorisierungsframework ermöglicht es einer Drittanbieteranwendung, eingeschränkten Zugriff auf einen HTTP-Dienst zu erhalten, entweder im Auftrag eines Ressourceninhabers, indem eine Genehmigungsinteraktion zwischen dem Ressourceninhaber und dem HTTP-Dienst orchestriert wird, oder durch Zulassen einer Drittanbieteranwendung, um Zugriff im eigenen Namen zu erhalten.“

Das Wichtigste ist, dass OAuth 2.0 eine Möglichkeit bietet, Anwendungen einen eingeschränkten Zugriff auf die geschützten Ressourcen eines Nutzers zu gewähren, z. B. Bankkonten oder andere vertrauliche Informationen, mit denen der Nutzer möglicherweise auf eine Anwendung zugreifen will, ohne dass der Nutzer seine Anmeldedaten für die Anwendung ableiten muss.

Tipp: Angenommen, Sie haben eine Anwendung gefunden, mit der Sie auf mehrere Bankkonten zugreifen können. Möglicherweise wird die App für Ihre Steuererklärung oder zur Verwaltung Ihres Budgets verwendet. Sie haben drei Bankkonten, die Sie mit der Anwendung verwalten möchten, und für jedes haben Sie einen anderen Nutzernamen und ein anderes Passwort. Damit die Anwendung auf Ihre Bankkonten zugreifen kann, sind diese vertraulichen Anmeldedaten erforderlich. Sie stellen diese vertraulichen Informationen normalerweise der Anwendung bereit. Möchten Sie der Anwendung Ihre Passwörter und Nutzernamen auch anvertrauen? Was passiert, wenn die App gehackt wird? In diesem Fall müssten Sie selbst daran denken, die Anmeldedaten für jedes Bankkonto zu ändern. Dies ist das grundlegende Problem, das von OAuth 2.0 gelöst wird. Weitere Informationen.

OAuth 2.0-Flow

Nachfolgend ist der allgemeine Ablauf für das OAuth 2.0-Sicherheitsframework dargestellt. Dieser Vorgang wird in diesem Thema ausführlich erörtert. Als Erstes wird gezeigt, wie OAuth 2.0 funktioniert. Wenn Sie mit den in diesem Diagramm verwendeten Begriffen nicht vertraut sind, lesen Sie die kurze Einführung in diesem Abschnitt.

Allgemeiner Ablauf für das OAuth 2.0-Sicherheitsframework.

Wichtige Begriffe

Kunde:auch App genannt. Dabei kann es sich um eine App handeln, die auf einem Mobilgerät oder auf einer traditionellen Web-Anwendung ausgeführt wird. Die Anwendung stellt im Namen des Ressourceninhabers Anfragen für den geschützten Inhalt an den Ressourcenserver. Der Ressourceninhaber muss der Anwendung Zugriff auf die geschützten Ressourcen gewähren.
Ressourceninhaber: Wird auch als Endnutzer bezeichnet. Dies ist im Allgemeinen die Person (oder eine andere Entität), die Zugriff auf eine geschützte Ressource gewähren kann. Wenn eine App beispielsweise Daten von einer Ihrer Websites in sozialen Medien verwenden muss, sind Sie der Ressourceninhaber. Dies ist die einzige Person, der der Anwendung Zugriff auf Ihre Daten gewährt.
Ressourcenserver: Stellen Sie sich den Ressourcenserver als Dienst wie Facebook, Google oder Twitter vor. oder einen Personalabteilung auf Ihrem Intranet oder einen Partnerdienst beim B2B-Extranet an. Apigee ist ein Ressourcenserver, wenn eine OAuth-Token-Validierung erforderlich ist, um API-Anfragen zu verarbeiten. Der Ressourcenserver benötigt eine Art von Autorisierung, bevor er geschützte Ressourcen an die Anwendung bereitstellt.
Autorisierungsserver: Der Autorisierungsserver ist gemäß der OAuth 2.0-Spezifikation implementiert und für die Validierung von Autorisierungsberechtigungen verantwortlich, sowie für die Bereitstellung der Zugriffstokens, die der Anwendung Zugriff auf die Daten auf dem Ressourcenserver gewähren. Sie können Token-Endpunkte in Apigee konfigurieren. In diesem Fall übernimmt Apigee die Rolle des Autorisierungsservers.
Autorisierungsberechtigung: Gewährt der Anwendung die Berechtigung, im Namen des Endnutzers ein Zugriffstoken abzurufen. In OAuth 2.0 sind vier Arten von „Berechtigungstypen“ definiert. Weitere Informationen finden Sie unter OAuth 2.0-Berechtigungstypen
Zugriffstoken: Ein langer String, der als Anmeldedaten für den Zugriff auf geschützte Ressourcen dient. Weitere Informationen finden Sie unter Was ist ein Zugriffstoken?.
Geschützte Ressource: Daten, die dem Ressourceninhaber gehören. Beispielsweise die Kontaktliste des Nutzers, Kontoinformationen oder andere vertrauliche Daten.

Rolle von Apigee

Sie können jede API mit Apigee 2.0 schützen. Apigee umfasst die Implementierung eines Autorisierungsservers und kann als solche Zugriffstokens generieren und validieren. Entwickler müssen ihre Anwendungen zuerst bei Apigee registrieren. Registrierte Anwendungen können Zugriffstokens über jede der vier Berechtigungstypen anfragen.

Apigee bietet eine mehrzeilige OAuthV2-Richtlinie, die Details zu jedem Berechtigungstyp implementiert. Dies erleichtert die Einrichtung von OAuth auf Apigee. Sie können beispielsweise eine Richtlinie konfigurieren, die eine Anfrage für ein Zugriffstoken empfängt, alle erforderlichen Anmeldedaten evaluiert und ein Zugriffstoken zurückgibt, wenn die Anmeldedaten gültig sind.

Beachten Sie, dass alle Ressourcenserver, die von Ihren sicheren API-Proxyaufrufen ausgeführt werden, hinter einer Firewall liegen müssen (d. h., die Ressourcen dürfen außer dem API-Proxy oder einer anderen gut geschützten API nur über die Ressourcen zugänglich sein).

Was sind OAuth 2.0-Berechtigungstypen?

Sie können die Art der Zuteilung als unterschiedliche Pfade oder Interaktionen betrachten, die eine Anwendung zum Abrufen eines Zugriffstokens ausführen kann. Jeder Berechtigungstyp ist für einen oder mehrere Anwendungsfälle vorgesehen. Sie müssen anhand Ihrer eigenen Anforderungen die zu verwendenden Typen auswählen. Im Allgemeinen hat jeder Berechtigungstyp Vorteile und Nachteile und Sie müssen die Vor- und Nachteile hinsichtlich Ihrer geschäftlichen Anwendungsfälle abwägen. Eine wichtige Überlegung ist die Vertrauenswürdigkeit der Anwendungen, die auf Ihre Daten zugreifen. Im Allgemeinen sind Drittanbieteranwendungen weniger vertrauenswürdig als Anwendungen, die innerhalb eines Unternehmens entwickelt und verwendet werden.

Apigee unterstützt die vier primären Berechtigungstypen von OAuth 2.0:

Autorisierungscode: Wird im Allgemeinen als sicherste Berechtigungstyp betrachtet. Bevor der Autorisierungsserver ein Zugriffstoken ausgibt, muss die Anwendung zuerst einen Autorisierungscode vom Ressourcenserver erhalten. Dieser Ablauf wird jedes Mal angezeigt, wenn Ihre Anwendung einen Browser auf der Anmeldeseite des Ressourcenservers öffnet und Sie einlädt, sich in Ihrem eigentlichen Konto anzumelden (z. B. Facebook oder Twitter).

Bei erfolgreicher Anmeldung erhält die Anwendung einen Autorisierungscode, mit dem sie ein Zugriffstoken beim Autorisierungsserver aushandeln kann. In der Regel wird diese Art von Berechtigungstyp verwendet, wenn sich die Anwendung auf einem Server statt auf dem Client befindet. Dieser Berechtigungstyp wird als äußerst sicher eingestuft, da die Clientanwendung den Nutzernamen oder das Passwort des Nutzers für den Ressourcenserver weder sieht noch verarbeitet. Beispielsweise kann die Anwendung Ihre Twitter-Anmeldedaten niemals sehen oder verarbeiten. Dieser Berechtigungstyp wird auch als dreibeiniges OAuth bezeichnet.

Implizit: Dies ist eine vereinfachte Version des Autorisierungscodes. Dieser Berechtigungstyp wird in der Regel verwendet, wenn sich die Anwendung auf dem Client befindet. Beispiel: Der Code der Anwendung wird in einem Browser mit JavaScript oder einer anderen Skriptsprache implementiert, anstatt auf einem separaten Webserver gespeichert und ausgeführt zu werden. Bei diesem Berechtigungstypablauf gibt der Autorisierungsserver direkt ein Zugriffstoken zurück, wenn der Nutzer authentifiziert wird. Dabei wird kein Autorisierungscode ausgegeben. Implizite Berechtigungen können die Reaktionsfähigkeit der Anwendung in einigen Fällen verbessern. Dieser Vorteil muss jedoch mit möglichen Sicherheitsrisiken abgewogen werden, die in der IETF-Spezifikation beschrieben sind.
Anmeldedaten des Ressourceninhabers: In diesem Ablauf erhält der Client ein Zugriffstoken, wenn der Nutzername/das Passwort des Nutzers vom Autorisierungsserver validiert wird. Dieser Ablauf wird für vertrauenswürdige Anwendungen empfohlen. Ein Vorteil dieses Ablaufs gegenüber der einfachen Authentifizierung beispielsweise ist, dass der Nutzer seinen Nutzernamen und sein Passwort nur einmal bereitstellt. Danach wird das Zugriffstoken verwendet.
Clientanmeldedaten: Verwenden Sie diese Option in Situationen, in denen die Clientanwendung in ihrem eigenen Namen agiert. Das heißt, der Client ist auch der Ressourceninhaber. Dieser Berechtigungstyp wird normalerweise verwendet, wenn die Anwendung beispielsweise auf einen Back-End-Datenspeicherdienst zugreifen muss. Die Anwendung muss den Dienst für ihre Arbeit verwenden und der Dienst ist für den Endnutzer intransparent. Mit diesem Berechtigungstyp erhält eine Anwendung ein Zugriffstoken, indem sie die Client-ID und den Clientschlüssel des Autorisierungsservers anzeigt. Sie müssen nichts weiter tun. bietet eine sofort einsatzbereite Lösung für Clientanmeldedaten, die für jeden API-Proxy einfach zu implementieren ist.

Was ist ein Zugriffstoken?

Ein Zugriffstoken ist eine lange Zeichenfolge, die als Anmeldedaten für geschützte Ressourcen dient. Ressourcen-Tokens (auch als „Inhabertokens“ bezeichnet) werden in Autorisierungs-Headern übergeben. Beispiel:

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

Der Ressourcenserver weiß, dass das Zugriffstoken für Anmeldedaten wie Nutzername und Passwort einsteht. Darüber hinaus können Zugriffstokens mit Einschränkungen versehen werden, sodass beispielsweise die Anwendung Daten auf dem Ressourcenserver lesen, aber nicht schreiben oder löschen kann. Beachten Sie, dass ein Zugriffstoken widerrufen werden kann, wenn beispielsweise die Anwendung manipuliert wurde. In diesem Fall müssen Sie ein neues Zugriffstoken anfordern, um die Anwendung weiterhin nutzen zu können. Allerdings müssen Sie Ihren Nutzernamen oder Ihr Passwort auf dem Server mit geschützten Ressourcen (z. B. Facebook oder Twitter) nicht ändern.

Aus Sicherheitsgründen haben Zugriffstokens in der Regel ein Ablaufdatum. Einige Berechtigungstypen erlauben es dem Autorisierungsserver, ein Aktualisierungstoken auszugeben. So kann die Anwendung nach Ablauf des alten Tokens ein neues Zugriffstoken abrufen. Weitere Informationen zu Zugriffs- und Aktualisierungstokens finden Sie in der IETF OAuth 2.0-Spezifikation.

Eingeschränkter Zugriff über Bereiche

Anhand des Mechanismus für Bereiche kann OAuth 2.0 einer Anwendung eingeschränkten Zugriff auf geschützte Ressourcen gewähren. Eine Anwendung kann beispielsweise folgende Berechtigungen haben: Zugriff auf bestimmte Ressourcen, Aktualisieren von Ressourcen oder Lesezugriff. Im Rahmen von sogenannten dreibeinigen OAuth-Abläufen gibt der Nutzer normalerweise die Zugriffsebene über eine Einwilligungsseite an (z. B. eine Webseite, auf der der Nutzer den Bereich durch Auswahl eines Kästchens oder über einen anderen Mechanismus auswählt).

Eine App registrieren

Alle Clients (Apps) müssen sich beim OAuth 2.0-Autorisierungsserver anmelden, von dem sie Zugriffstoken anfordern möchten. Wenn Sie eine App registrieren, erhalten Sie eine Reihe von Schlüsseln. Einer der Schlüssel ist der öffentliche Schlüssel, der als Client-ID bezeichnet wird, der andere ein geheimer Schlüssel, der als Clientschlüssel bezeichnet wird. Ohne diese Schlüssel kann eine Anwendung keine Autorisierungscodes oder Zugriffstokens an den Autorisierungsserver senden. Während die IETF-OAuth-Spezifikation diese Schlüssel als Client-ID und Client-Schlüssel bezeichnet, werden sie von der Apigee-Benutzeroberfläche Consumer-ID und Consumer-Secret genannt. Sie sind gleichwertig.

Zusammenfassung der OAuth 2.0-Anwendungsfälle

Sie wählen den OAuth 2.0-Berechtigungstyp für die Implementierung abhängig vom jeweiligen Anwendungsfall aus, da einige Berechtigungstypen sicherer als andere sind. Die Auswahl der Berechtigungstypen hängt von der Vertrauenswürdigkeit der Clientanwendung ab und erfordert sehr sorgfältige Überlegungen:

Anwendungsfall	Vertrauenswürdigkeit	Empfohlene OAuth 2.0-Berechtigungstypen zur Autorisierung	Beschreibung
B2B (Extranet), Intranet, sonstige	Sehr vertrauenswürdige Anwendungen, die von internen Entwicklern oder Entwicklern mit einer vertrauenswürdigen Geschäftsbeziehung mit dem API-Anbieter geschrieben wurden. Anwendungen, die in ihrem Namen auf Ressourcen zugreifen müssen.	Clientanmeldedaten	In der Regel ist die Anwendung auch der Ressourceninhaber. Erfordert Client-ID und Clientschlüssel. Die Anwendung muss beim Dienstanbieter registriert sein.
Intranet-Websites, Portale	Vertrauenswürdige Anwendungen von internen oder vertrauenswürdigen externen Entwicklern. Ein gutes Beispiel ist die Anmeldung in der Personalwebsite Ihres Unternehmens, um eine Versicherungsauswahl zu treffen, Bewertungen einzureichen oder personenbezogene Daten zu ändern.	Passwort Implizit	Erfordert Client-ID und Secret sowie Nutzername und Passwort. Die Anwendung muss beim Dienstanbieter registriert sein.
Öffentlich verfügbare Anwendungen	Nicht vertrauenswürdige Anwendungen wurden von Drittanbietern geschrieben, die keine vertrauenswürdige Geschäftsbeziehung mit dem API-Anbieter haben. Beispielsweise sollten Entwickler, die sich für öffentliche API-Programme registrieren, nicht allgemein vertrauenswürdig sein.	Autorisierungscode	Der Nutzer muss sich bei einem Drittanbieter-Ressourcenanbieter anmelden (z. B. Twitter, Facebook) Der Nutzername und das Passwort des Nutzers werden nie angezeigt. Die Anwendung muss beim Dienstanbieter registriert sein.
B2C	Es gibt einen einzelnen Endnutzer (mobiler Nutzer) und die Nutzeranmeldedaten werden auf dem Mobilgerät gespeichert.	Implizit	Die Anwendung muss beim Dienstanbieter registriert sein. Die Nutzeranmeldedaten werden auf dem Gerät gespeichert, auf dem die Anwendung ausgeführt wird.

OAuth 2.0 im Vergleich zur API-Schlüsselsicherheit

Zur Validierung von API-Schlüsseln muss eine Anwendung einen Schlüssel an Apigee senden. Der Schlüssel muss ein gültiger Consumer-Schlüssel einer Apigee-Entwickler-App sein, die mit dem API-Proxy verknüpft ist. Wenn Sie die Berechtigung einer Client-App zum Aufrufen eines Proxys widerrufen müssen, müssen Sie diesen Consumer-Schlüssel widerrufen. Client-Apps, die diesen Schlüssel verwenden, können nicht auf den API-Proxy zugreifen. Andererseits kann ein OAuth-Token jederzeit widerrufen werden, ohne die Schlüssel der Anwendung zu widerrufen. Die Anwendung kann einfach ein neues Token für den Nutzer anfordern. Wenn ein Token gewährt wird, kann die Anwendung weiterhin den API-Proxy verwenden.

Ein weiterer Unterschied zwischen einem API-Schlüssel und einem Token ist, dass ein Token Metadatenattribute enthalten kann, die Sie später abrufen und verwenden können. Beispielsweise können Sie die ID des Nutzers speichern, der den API-Aufruf durchführt, und damit Aufrufe für den Back-End-Zieldienst anpassen.

Weitere Informationen zur API-Schlüsselvalidierung finden Sie unter API-Schlüssel. Informationen zur Verwendung von benutzerdefinierten Attributen mit OAuth-Tokens finden Sie unter Tokens und Autorisierungscodes anpassen.

Empfohlene Ressourcen

Lesen

Weitere Informationen zu OAuth 2.0