Diese Seite wurde von der Cloud Translation API übersetzt.

Einführung in OAuth 2.0

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

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 auf Apigee Edge.

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.“

Wichtig ist vor allem, dass OAuth 2.0 Anwendungen ermöglicht, eingeschränkten Zugriff auf die geschützten Ressourcen eines Nutzers zu erhalten (z. B. auf das Bankkonto oder andere vertrauliche Daten, auf die ein Nutzer über eine Anwendung zugreifen möchte), ohne dass der Nutzer seine Anmeldedaten an die Anwendung weitergeben 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.

Wichtige Begriffe

Client:Wird auch als „die App“ bezeichnet. Dies kann eine auf einem Mobilgerät ausgeführte App oder eine herkömmliche Web-App sein. Die App stellt im Namen des Ressourceninhabers Anfragen für geschützte Assets 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 Edge ist ein Ressourcenserver, wenn eine OAuth-Tokenvalidierung 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 "Tokenendpunkte" in Apigee Edge konfigurieren. In diesem Fall übernimmt Edge 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 unten im Abschnitt Was sind die OAuth 2.0-Berechtigungsarten?.
Zugriffstoken: Ein langer String, der als Anmeldedaten für den Zugriff auf geschützte Ressourcen dient. Weitere Informationen finden Sie unten im Abschnitt 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 Edge

Sie können alle APIs, die über Apigee Edge weitergeleitet werden, mit OAuth 2.0 schützen. Edge enthält eine Autorisierungsserverimplementierung und kann daher Zugriffstokens generieren und validieren. Entwickler registrieren ihre Apps zuerst bei Apigee Edge. Registrierte Anwendungen können Zugriffstokens über jede der vier Berechtigungstypen anfragen.

Apigee bietet eine vielschichtige OAuthV2-Richtlinie, in der die Details jedes Berechtigungstyps implementiert sind, was die Einrichtung von OAuth auf Apigee Edge relativ einfach macht. 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 deckt einen oder mehrere Anwendungsfälle ab. Sie müssen entsprechend Ihren eigenen Anforderungen auswählen, welche Berechtigungstypen Sie verwenden möchten. Im Allgemeinen hat jeder Berechtigungstyp Vorteile und Nachteile und Sie müssen die Vor- und Nachteile hinsichtlich Ihrer geschäftlichen Anwendungsfälle abwägen. Ein wichtiger Aspekt 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 Edge unterstützt die vier Hauptzuteilungstypen für 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. Sie sehen diesen Vorgang immer dann, wenn Ihre App einen Browser für die Anmeldeseite des Ressourcenservers öffnet und Sie einlädt, sich in Ihrem tatsächlichen Konto (z. B. Facebook oder Twitter) anzumelden.

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 Vorgang 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. Edge 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 versteht, dass das Zugriffstoken für Anmeldedaten wie Nutzername und Passwort „steht“. 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. Bei einigen Berechtigungstypen kann der Autorisierungsserver ein Aktualisierungstoken ausstellen, sodass die App ein neues Zugriffstoken abrufen kann, wenn das alte abläuft. 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. Bei sogenannten „dreibeinigen“ OAuth-Abläufen gibt der Nutzer die Zugriffsebene in der Regel über eine Einwilligungsseite an (z. B. eine Webseite, auf der der Nutzer den Bereich über ein Kästchen eines 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. Beachten Sie, dass die IETF-OAuth-Spezifikation diese Schlüssel die Client-ID und den Clientschlüssel aufruft, in der Apigee Edge-Benutzeroberfläche aber die Consumer-ID und das Consumer-Secret. 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	Besonders vertrauenswürdige Apps, die von internen Entwicklern oder Entwicklern mit einer vertrauenswürdigen Geschäftsbeziehung mit dem API-Anbieter verfasst wurden. Anwendungen, die in ihrem Namen auf Ressourcen zugreifen müssen.	Clientanmeldedaten	In der Regel ist die App 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 auf der Website der Personalabteilung Ihres Unternehmens, um eine Versicherung auszuwählen, Rezensionen 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 App 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

Für die API-Schlüsselvalidierung muss eine App einen Schlüssel an Edge senden. Der Schlüssel muss ein gültiger Consumer-Key aus einer Apigee Edge-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. Sie können beispielsweise die ID des Nutzers, der den API-Aufruf durchführt, speichern und verwenden, um Aufrufe an den Back-End-Zieldienst anzupassen.

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

Siehe Informationen zu OAuth 2.0.