<ph type="x-smartling-placeholder"></ph>
Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie 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 einen grundlegenden Überblick ü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.“
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.
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 „App“ bezeichnet. Das kann eine App sein, die auf einem Mobilgerät oder eine herkömmliche Web-App nutzen. Die Anwendung sendet Anfragen an den Ressourcenserver für geschützte Assets im Namen des Ressourceninhabers 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-Token-Validierung erforderlich ist, um 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. Ich kann „Tokenendpunkte“ konfigurieren auf Apigee Edge. In diesem Fall übernimmt Edge die Rolle eines Autorisierungsserver.
- Autorisierungsberechtigung: Gewährt der Anwendung die Berechtigung, im Namen des Endnutzers ein Zugriffstoken abzurufen. In OAuth 2.0 sind vier Arten von „Berechtigungstypen“ definiert. Siehe Welche OAuth 2.0-Berechtigungstypen gibt es? unten.
- Zugriffstoken: Ein langer String, der als Anmeldedaten für den Zugriff auf geschützte Ressourcen dient. Siehe auch Was ist ein Zugriff? Token?" unten.
- 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 ein Implementierung des Autorisierungsservers und als solche können Zugriffstokens generieren und validieren. Entwickler beginnen damit, ihre Apps bei Apigee Edge zu registrieren. Registrierte Anwendungen können Zugriffstokens über jede der vier Berechtigungstypen anfragen.
Apigee bietet eine facettenreiche OAuthV2-Richtlinie zur Implementierung des Details zu jeder Art der Erteilung, was die Einrichtung von OAuth auf Apigee Edge vereinfacht. 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 eignet sich für einen oder mehrere Anwendungsfälle und Sie müssen auswählen, welche Erteilung Typen, die Sie je nach Ihren Anforderungen verwenden können. Im Allgemeinen hat jeder Berechtigungstyp Vorteile und Nachteile und Sie müssen die Vor- und Nachteile hinsichtlich Ihrer geschäftlichen Anwendungsfälle abwägen. Eins ist die „Vertrauenswürdigkeit“ die auf Ihre Daten zugreifen werden. Im Allgemeinen sind Drittanbieteranwendungen weniger vertrauenswürdig als Anwendungen, die innerhalb eines Unternehmens entwickelt und verwendet werden.
Apigee Edge unterstützt die vier Haupt-OAuth 2.0-Berechtigungstypen:
- Autorisierungscode: Wird im Allgemeinen als sicherste Berechtigungstyp betrachtet. Bevor der Autorisierungsserver ein Zugriffstoken ausgibt, muss die Anwendung zuerst einen Autorisierungscode vom Ressourcenserver erhalten. Sie haben diesen Ablauf immer gesehen, wenn Ihre App einen Browser und lädt Sie ein, sich in Ihrem 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 Vorgang wird auch als „dreibeinige“ bezeichnet OAuth
- 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 Client-Anmeldedaten, die für alle API-Proxy.
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. 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 Erteilungstypen Autorisierungsserver, ein Aktualisierungstoken auszustellen, mit dem die App ein neues Zugriffstoken abrufen kann wenn die 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. Unter den sogenannten "dreibeinigen" OAuth-Abläufe In der Regel gibt der Nutzer die Zugriffsebene über eine Einwilligungsseite (z. B. eine Webseite) an. Der Nutzer wählt den Umfang über ein Kästchen eines anderen Mechanismus aus.
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 OAuth-Spezifikation von IETF diese Schlüssel aufruft, ID und den Clientschlüssel verwendet, nennt die Apigee Edge-Benutzeroberfläche sie die Consumer-ID und den 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 |
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. |
|
|
| 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. |
|
|
| Ö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. |
|
|
| B2C | Es gibt einen einzelnen Endnutzer (mobiler Nutzer) und die Nutzeranmeldedaten werden auf dem Mobilgerät gespeichert. |
|
|
OAuth 2.0 im Vergleich zur API-Schlüsselsicherheit
Für die Validierung des API-Schlüssels muss eine App einen Schlüssel an Edge senden. Der Schlüssel muss ein gültiger Consumer-Key sein aus einer Apigee Edge-Entwickler-App, 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.