Diese Seite wurde von der Cloud Translation API übersetzt.

OAuth-Tokens von Drittanbietern verwenden

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

In diesem Thema wird erläutert, wie extern generierte Zugriffstokens, Aktualisierungstokens oder Authentifizierungscodes in den Edge-Tokenspeicher importiert werden. Sie können diese Technik verwenden, wenn Sie Apigee Edge so konfigurieren möchten, dass Tokens validiert werden, die außerhalb von Apigee Edge generiert wurden.

Im Normalfall generiert und speichert Apigee Edge ein OAuth-Token und gibt es an die aufrufende App zurück. Die aufrufende App stellt das Token dann beim Anfordern von Diensten wieder in Apigee Edge bereit und Apigee Edge prüft unter Verwendung der OAuthV2-Richtlinie mit Operation = VerifyAccessToken, ob das Token gültig ist. In diesem Thema wird beschrieben, wie Sie Apigee Edge so konfigurieren können, dass ein extern generiertes OAuth-Token gespeichert wird, ohne die Tokenprüfung zu ändern – so, als ob das Token von Edge generiert wurde.

Beispiel

Eine Anwendung, die das in diesem Thema beschriebene Verfahren veranschaulicht, bietet das Beispiel Apigee Delegated Token Management.

Was ist das?

Angenommen, Sie haben ein bestehendes Autorisierungssystem und möchten von diesem System generierte Tokens oder Codewerte anstelle der von Edge generierten Tokens oder Codewerte verwenden. Sie können dann sichere API-Proxy-Anfragen mit dem Ersatztoken oder -code erstellen und Edge prüft das Token oder den Code, als ob es/er von Edge generiert wurde.

Hintergrund

Normalerweise generiert Apigee Edge ein Token in Form eines zufälligen Strings aus Buchstaben und Zahlen. Apigee Edge verknüpft dieses Token mit anderen Daten wie der Ausstellungszeit, der Ablaufzeit, der Liste der API-Produkte, für die das Token gültig ist, und den Bereich. Alle diese Informationen können in einer Antwort zurückgegeben werden, die automatisch von der OAuthV2-Richtlinie mit Operation = GenerateAccessToken generiert wird. Die Antwort sieht so aus:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "zBC90HhCGmGlaMBWeZAai2s3za5j",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

Der Wert des Attributs access_token ist praktisch der Suchschlüssel für die Antwortdaten. Eine Anwendung könnte eine Anfrage an einen in Edge gehosteten API-Proxy senden, der das Inhabertoken zBC90HhCGmGlaMBWeZAai2s3za5j enthält, und Edge – mit der OAuthV2-Richtlinie mit Operation = VerifyAccessToken – ruft das Token für den angeforderten API-Proxy auf, ruft alle Informationen ab und verwendet diese Informationen, um festzustellen, ob das Token gültig ist oder nicht. Das wird als Tokenvalidierung bezeichnet. Alle oben aufgeführten Informationen umfassen das Token. Der Wert "access_token" ist nur die Möglichkeit, diese Informationen abzurufen.

Wenn Sie dagegen die hier beschriebenen Schritte ausführen, können Sie Edge so konfigurieren, dass ein Token gespeichert wird, sodass der Wert access_token etwas ist, das von einem externen Dienst generiert wurde. Alle anderen Metadaten können identisch sein. Angenommen, Sie haben ein System außerhalb von Apigee Edge, das Tokens in der Form "TOKEN-<16 Zufallszahlen>" generiert. In diesem Fall könnten die vollständigen von Apigee Edge gespeicherten Token-Metadaten so aussehen:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "TOKEN-1092837373654221",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

In diesem Fall könnte eine Anwendung eine Anfrage an einen in Edge gehosteten API-Proxy senden, der das Inhabertoken TOKEN-1092837373654221 enthält, und Edge kann sie – über die OAuthV2-Richtlinie mit „Operation =VerifyAccessToken“ – validieren. Sie können ein ähnliches Importmuster auf Autorisierungscodes und Aktualisierungstokens anwenden.

Anmeldedaten von Clients prüfen

Eine Voraussetzung für die Generierung eines Tokens ist die Prüfung des anfragenden Clients. Standardmäßig werden die Anmeldedaten des Clients mit der Richtlinie "OAuthV2/GenerateAccessToken" in Apigee Edge implizit geprüft. In einer Anfrage für ein OAuthV2-Token werden Client-ID und Clientschlüssel normalerweise im Autorisierungsheader übergeben. Die Verschlüsselung erfolgt über eine HTTP-Basisautorisierung (verkettet durch Doppelpunkt, dann Base64-Codierung). Die OAuthV2/GenerateAccessToken-Richtlinie in Apigee Edge decodiert diesen Header, sucht die Client-ID und prüft, ob der übergebene Clientschlüssel für diese Client-ID gültig ist. Dies funktioniert, wenn Apigee Edge die Anmeldedaten kennt. Mit anderen Worten: In Apigee Edge ist eine Entwickler-App gespeichert, die Anmeldedaten enthält, die wiederum die angegebene Client-ID und den Clientschlüssel enthalten.

Falls die Clientanmeldedaten nicht von Apigee Edge validiert werden, müssen Sie Ihren API-Proxy so konfigurieren, dass der Client vor Generierung eines Tokens auf andere Weise explizit geprüft wird. Dies geschieht häufig über eine ServiceCallout-Richtlinie, die eine Verbindung zu einem Remote-Endpunkt in Ihrem Netzwerk herstellt.

Auf die eine oder andere Weise – implizit oder explizit – müssen Sie zuerst dafür sorgen, dass der API-Proxy, der Tokens generiert, zuerst die Clientanmeldedaten validiert. Die Validierung des Clients ist unabhängig von der Generierung des Zugriffstokens. Sie können Apigee Edge so konfigurieren, dass beides, eine der beiden oder keines davon ausgeführt wird.

Wenn Sie möchten, dass die Richtlinie „OAuthV2/GenerateAccessToken“ in Apigee Edge die Clientanmeldedaten anhand des Edge-Speichers validiert, setzen Sie das Element <ExternalAuthorization> in der Richtlinienkonfiguration auf false oder lassen Sie es weg. Wenn Sie einen externen Autorisierungsdienst verwenden möchten, um die Anmeldedaten des Clients explizit zu validieren, setzen Sie <ExternalAuthorization> auf true.

Obwohl Apigee Edge die Clientanmeldedaten möglicherweise nicht validiert, muss die client_id dennoch von Apigee Edge bekannt sein und verwaltet werden. Jedes Zugriffstoken in Apigee Edge muss mit einer Clientanwendung verknüpft sein, die von Apigee Edge generiert oder von einem externen System generiert und dann in Apigee Edge importiert wurde. Dies wird durch die client_id angegeben. Selbst in dem Fall, dass die OAuthV2/GenerateAccessToken-Richtlinie in Apigee Edge nicht validiert, dass client_id und client_secret übereinstimmen, validiert die Richtlinie, dass die client_id gültig, vorhanden und nicht widerrufen ist. Als erforderlicher Einrichtungsschritt müssen Sie daher möglicherweise client_ids über die administrative Edge-API importieren.

Richtlinienablauf für OAuth von Drittanbietern auf Apigee

Wenn Sie Tokens von OAuth-Systemen von Drittanbietern in Apigee Edge verwenden möchten, sollte der Ablauf zum Generieren von Zugriffstokens einem der folgenden Muster folgen.

Externe Validierung von Clientanmeldedaten

ServiceCallout, um die eingehenden Clientanmeldedaten zu prüfen und ein externes Token abzurufen.
ExtractVariables oder ein JavaScript-Schritt, um das extern generierte Token aus der Antwort zu extrahieren.
AssignMessage, um die spezielle bekannte Variable oauth_external_authorization_status festzulegen. Der Wert muss "true" sein, damit die Clientanmeldedaten gültig sind.
OAuthV2/GenerateAccessToken mit dem Element <ExternalAuthorization> auf true gesetzt und mindestens einem <ExternalAccessToken>, <ExternalRefreshToken> oder <ExternalAuthorizationCode>.

Interne Prüfung der Clientanmeldedaten

ServiceCallout, um ein externes Token abzurufen.
ExtractVariables oder ein JavaScript-Schritt, um das extern generierte Token aus der Antwort zu extrahieren.
OAuthV2/GenerateAccessToken mit dem Element <ExternalAuthorization> auf false gesetzt und mindestens einem <ExternalAccessToken>, <ExternalRefreshToken> oder <ExternalAuthorizationCode>.

Hinweise zum Ablauf und zur Richtlinienkonfiguration

Wenn Sie zur Überprüfung der Clientanmeldedaten ein externes System verwenden möchten, müssen Sie einen Richtlinienablauf entwickeln, der die erforderlichen Maßnahmen durchführt. Normalerweise verwenden Sie eine ServiceCallout-Richtlinie, um die extern erkannten Anmeldedaten an den externen Authentifizierungsdienst zu senden. Der externe Authentifizierungsdienst gibt in der Regel eine Antwort zurück und, falls die Anmeldedaten gültig sind, auch ein Zugriffstoken.
Nach der Verwendung von ServiceCallout muss der API-Proxy die Antwort parsen, um den Gültigkeitsstatus sowie das extern generierte Zugriffstoken und möglicherweise das Aktualisierungstoken zu extrahieren.
Setzen Sie in der OAuthV2/GenerateAccessToken-Richtlinie das Element <StoreToken> auf true und setzen Sie das Element <ExternalAuthorization> entsprechend auf true oder false.

Wenn die OAuthV2/GenerateAccessToken-Richtlinie ausgeführt wird, liest sie die Variable oauth_external_authorization_status. Wenn die Variable festgelegt und der Wert wahr ist, versucht Apigee Edge nicht, die Clientanmeldedaten zu validieren. Wenn die Variable nicht festgelegt oder der Wert nicht wahr ist, versucht Apigee Edge, Clientanmeldedaten zu validieren.
Für die OAuthV2-Richtlinie gibt es drei Elemente, mit denen Sie die zu importierenden externen Daten angeben können: <ExternalAccessToken>, <ExternalRefreshToken> und <ExternalAuthorizationCode>. Jedes dieser Elemente akzeptiert eine Ablaufvariable. Die Edge-Richtlinie liest diese Variable, um das extern generierte Zugriffstoken, das Aktualisierungstoken oder den Autorisierungscode zu finden. Es liegt bei Ihnen, Richtlinien und Logik zu implementieren, um die externen Tokens oder Codes in den entsprechenden Variablen zu platzieren.

Die folgende Konfiguration in der OAuthV2-Richtlinie weist beispielsweise Edge an, in einer Kontextvariablen namens external_token nach dem Token zu suchen.
```
<ExternalAccessToken>external_token</ExternalAccessToken>
```
Diese Variable muss in einem vorherigen Schritt festgelegt werden.

Eine gängige Methode zum Festlegen der Variablen oauth_external_authorization_status besteht darin, eine AssignMessage-Richtlinie mit dem AssignVariable-Element so zu verwenden:

<AssignMessage name="AssignMessage-SetVariable">
    <DisplayName>Assign Message - Set Variable</DisplayName>
    <AssignVariable>
        <Name>oauth_external_authorization_status</Name>
        <Value>true</Value>
    </AssignVariable>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

Beachten Sie, dass diese Richtlinie vor der OAuthV2-Richtlinie mit Operation = GenerateAccessToken liegen muss.

Beispiel für eine OAuthV2-Richtlinie

Die folgende OAuthV2-Richtlinie generiert ein Apigee Edge-Zugriffstoken, sofern Edge einen Tokenwert in der Flussvariablen external_access_token findet.

<OAuthV2 name="OAuth-v20-Store-External-Token">
    <ExternalAccessToken>external_access_token</ExternalAccessToken>
    <ExternalAuthorization>true</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <GenerateResponse enabled="true">
        <Format>FORM_PARAM</Format>
    </GenerateResponse>
    <ReuseRefreshToken>false</ReuseRefreshToken>
    <StoreToken>true</StoreToken>
    <SupportedGrantTypes>
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <ExpiresIn ref='flow.variable'>2400000</ExpiresIn>
</OAuthV2>

Normalerweise müssen Sie bei der Gewährung von Clientanmeldedaten einen Basisauthentifizierungsheader mit der codierten Client-ID und dem Clientschlüssel angeben. In diesem Fall müssen Sie diesen Header jedoch nicht angeben. Die Richtlinie erwartet weiterhin, dass client_id in der Anfrage vorhanden ist, und validiert sie. Edge erwartet, dass client_id als Teil der Anfrageformulardaten gesendet wird, z.B. in request.formparam.client_id.

Theoretisch können Sie dieses Muster mit jedem OAuth2-Autorisierungsdienst eines Drittanbieters anwenden.