Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

OAuth-Tokens von Drittanbietern verwenden

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu Apigee X. info

In diesem Thema wird erläutert, wie extern generierte Zugriffstokens, Aktualisierungstokens, oder Autorisierungscodes in den Edge-Token-Speicher 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 werden.

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 der Suchschlüssel für die Antwortdaten. Eine Anwendung könnte an einen in Edge gehosteten API-Proxy eine Anfrage stellen, die das Inhabertoken zBC90HhCGmGlaMBWeZAai2s3za5j enthält, und Edge – mit der OAuthV2 Richtlinie mit Operation = VerifyAccessToken – schlägt das Token nach, ruft alle Informationen ab und ermittelt anhand dieser Informationen, ob das Token für den angeforderten API-Proxy 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 die hier beschriebenen Schritte ausführen, können Sie Edge so konfigurieren, dass ein Token gespeichert wird, dessen access_token -Wert von einem externen Dienst generiert wird. Alle anderen Metadaten können identisch sein. Angenommen, Sie haben ein System außerhalb von Apigee Edge, das Tokens im Format "TOKEN-<16 Zufalls zahlen>" generiert. In diesem Fall lauten die vollständigen, von Apigee Edge gespeicherten Token-Metadaten z. B.:

{
  "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 an einen in Edge gehosteten API-Proxy eine Anfrage stellen, die das Inhaber token TOKEN-1092837373654221 enthält, und Edge – über die OAuthV2-Richtlinie mit Operation = VerifyAccessToken – kann es dann 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.

Mit einer der beiden Methoden, entweder implizit oder explizit, müssen Sie 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 dafür konfigurieren, beides zu tun, oder nur eines oder nichts davon.

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

Apigee Edge validiert die Anmeldedaten des Clients zwar möglicherweise nicht, aber die client_id muss bekannt sein und von Apigee Edge verwaltet werden. Jedes access_token in Apigee Edge, ob es von Apigee Edge generiert wird oder von einem externen System generiert und dann in Apigee Edge importiert wird, muss einer Clientanwendung zugeordnet sein, die durch die client_id angegeben wird. Selbst wenn die OAuthV2/GenerateAccessToken-Richtlinie in Apigee Edge nicht überprüft, ob client_id und client_secret übereinstimmen, prüft die Richtlinie, ob die client_id gültig, vorhanden und nicht widerrufen ist. In diesem Fall müssen Sie möglicherweise zuvor client_id über die administrative Edge API importieren.

Richtlinienablauf für OAuth von Drittanbietern auf Apigee

Zur Verwendung von Tokens aus OAuth-Drittanbietersystemen in Apigee Edge sollte der Ablauf zum Generieren von Zugriffs tokens 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 ist und der Wert true ist, versucht Apigee Edge nicht, die Clientanmeldedaten zu überprüfen. Wenn die Variable nicht festgelegt oder der Wert nicht "true" ist, versucht Apigee Edge, die Anmeldedaten des Clients 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, wenn Edge einen Tokenwert in der Ablaufvariablen 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 Prüfung der Clientanmeldedaten einen Basisauthentifizierungs-Header mit der codierten Client-ID und dem Clientschlüssel bereitstellen. In diesem Fall muss der Header jedoch nicht angegeben werden. Die Richtlinie erwartet weiterhin, dass die client_id in der Anfrage vorhanden ist, und die Richtlinie validiert sie. Edge erwartet, dass die 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.