Diese Seite wurde von der Cloud Translation API übersetzt.

OAuth-Tokens von Drittanbietern verwenden

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

In diesem Thema erfahren Sie, wie Sie extern generierte Zugriffstokens, Aktualisierungstokens oder Auth-Codes in den Edge-Tokenspeicher. Sie können diese Technik verwenden, Konfigurieren Sie Apigee Edge, um Tokens zu validieren, 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 effektiv der Suchschlüssel für die Antwortdaten. Eine App könnte eine Anfrage an einen in Edge gehosteten API-Proxy senden, mit dem Inhabertoken zBC90HhCGmGlaMBWeZAai2s3za5j und Edge – mit dem OAuthV2- Richtlinie mit Operation = VerifyAccessToken - ruft das Token ab, ruft alle Informationen ab und verwenden diese Informationen, um zu bestimmen, 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.

Auf der anderen Seite können Sie mit den hier beschriebenen Schritten Edge für das Speichern eines ein, sodass sein Wert access_token von einem externen Rechner 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 random“ generiert. Zahlen>“ . In diesem Fall könnten die von Apigee Edge gespeicherten vollständigen Tokenmetadaten wie folgt lauten:

{
  "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 App eine Anfrage an einen in Edge gehosteten API-Proxy senden, der den Inhaber Token TOKEN-1092837373654221 und Edge – über die OAuthV2-Richtlinie mit Operation = VerificationAccessToken – kann es 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.

Sie müssen entweder implizit oder explizit darauf achten, dass der API-Proxy zum Generieren von Tokens, validiert zuerst die Clientanmeldedaten. Die Validierung des Clients ist unabhängig von der Generierung des Zugriffstokens. Sie können Apigee Edge für beides konfigurieren, das eine oder das andere tun oder auch nichts.

Wenn Sie möchten, dass die Richtlinie OAuthV2/GenerateAccessToken in Apigee Edge den Client validiert Anmeldedaten für den Edge-Speicher zu verwenden, legen Sie das Element <ExternalAuthorization> auf false in der Richtlinienkonfiguration einfügen oder ganz weglassen. 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 Client-Anmeldedaten möglicherweise nicht validiert, ist es dennoch für den client_id soll von Apigee Edge bekannt und verwaltet werden. Jedes Zugriffstoken in Apigee Edge, ob die von Apigee Edge oder einem externen System generiert und dann in Apigee Edge importiert werden. muss einer Clientanwendung zugeordnet sein (durch die client_id angegeben). Selbst im Fall von wobei die Richtlinie OAuthV2/GenerateAccessToken in Apigee Edge nicht prüft, ob die client_id und „client_secret“ übereinstimmen, prüft die Richtlinie, ob die Client-ID gültig, vorhanden und nicht widerrufen. Als Voraussetzung für die Einrichtung müssen Sie also möglicherweise client_ids über den Edge-Browser importieren. administratives API.

Richtlinienablauf für OAuth von Drittanbietern auf Apigee

Um Tokens von OAuth-Systemen von Drittanbietern in Apigee Edge zu verwenden, der Ablauf zum Generieren des Zugriffs Tokens müssen 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 wahr, dann versucht Apigee Edge nicht, die Clientanmeldedaten zu validieren. Wenn die Variable nicht festgelegt ist oder der Wert nicht wahr ist, versucht Apigee Edge, den Client zu validieren. Anmeldedaten.
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 die ein extern generiertes Zugriffstoken, Aktualisierungstoken oder Autorisierungscode. 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 ein Tokenwert in der Flussvariablen external_access_token.

<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 muss mit dem Client Berechtigungstyp der Anmeldedaten gewähren, müssen Sie einen Basisauthentifizierungs-Header mit dem codierten Client ID und Clientschlüssel. In diesem Fall ist es jedoch nicht erforderlich, Header. Für die Richtlinie wird weiterhin erwartet, dass das client_id in der Anfrage vorhanden ist und die überprüft. Edge erwartet, dass die client_id als Teil gesendet wird der Anfrageformulardaten, z.B. in request.formparam.client_id.

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