Cette page a été traduite par l'API Cloud Translation.

Utiliser des jetons OAuth tiers

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Dans cette rubrique, nous verrons comment importer des jetons d'accès générés en externe, actualiser ou les codes d'autorisation dans le magasin de jetons Edge. Vous pouvez utiliser cette technique si vous souhaitez configurer Apigee Edge pour valider les jetons générés en dehors d'Apigee Edge.

Habituellement, Apigee Edge génère et stocke un jeton OAuth, puis le renvoie à l'application appelante. L'application appelante présente ensuite ce jeton à Apigee Edge lors de la demande de service, et Apigee Edge vérifie que le jeton est valide (via la stratégie OAuthV2 avec Operation = VerifyAccessToken). Cette rubrique explique comment configurer Apigee Edge pour stocker un jeton OAuth généré à l'extérieur, tout en conservant la même partie de la validation, comme si le jeton avait été généré par Edge.

Exemple

Si vous souhaitez voir un exemple fonctionnel illustrant les techniques décrites dans cette rubrique, consultez l'exemple de gestion des jetons déléguée d'Apigee.

Plus d'infos

Supposons que vous disposez d'un système d'autorisation existant et que vous souhaitiez utiliser les valeurs de jeton ou de code générées par ce système au lieu du jeton ou du code de protocole OAuth2 générés par Edge. Vous pouvez ensuite effectuer des demandes sécurisées de proxy d'API avec un jeton ou un code substitué. Edge les validera comme si elles avaient été générées par Edge.

Informations générales

Dans le cas habituel, Apigee Edge génère un jeton en produisant une chaîne de lettres aléatoire et de chiffres. Apigee Edge associe à ce jeton d'autres données telles que l'heure à laquelle le jeton a été émis, l'expiration, la liste des produits d'API pour lesquels le jeton est valide, ainsi que le champ d'application. Toutes ces informations peuvent être renvoyées dans une réponse générée automatiquement par la stratégie OAuthV2 configurée avec l'opération Operation = GenerateAccessToken. La réponse est semblable à ce qui suit :

{
  "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"
}

La valeur de l'attribut access_token est effectivement la clé de recherche de les données de réponse. Une application peut envoyer une demande à un proxy d'API hébergé dans Edge, transportant le jeton de support zBC90HhCGmGlaMBWeZAai2s3za5j et Edge, avec le protocole OAuthV2 avec Operation = VerifyAccessToken : recherche le jeton, récupère toutes les informations et utiliser ces informations pour déterminer si le jeton est valide ou non, pour le proxy d'API demandé. C'est ce qu'on appelle la validation de jeton. Toutes les informations ci-dessus comprennent le jeton. La valeur access_token est un moyen de rechercher cette information.

D'autre part, en suivant les étapes décrites ici, vous pouvez configurer Edge pour stocker un de sorte que sa valeur access_token soit un élément généré par une Google Cloud. Toutes les autres métadonnées peuvent être identiques. Par exemple, supposons que vous ayez un système Externe à Apigee Edge, qui génère des jetons au format "TOKEN-<16 random" chiffres>" pour en savoir plus. Dans ce cas, les métadonnées de jeton complètes stockées par Apigee Edge peuvent être:

{
  "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"
}

Dans ce cas, une application peut envoyer une demande à un proxy d'API hébergé dans Edge, portant le support jeton TOKEN-1092837373654221, et Edge - via la règle OAuthV2 avec Operation = VerifyAccessToken - pourra le valider. Vous pouvez appliquer un schéma d'importation similaire aux codes d'autorisation et aux jetons d'actualisation.

Voyons comment valider les identifiants client

L'une des conditions préalables à la génération d'un jeton consiste à valider le client demandeur. Par défaut, La règle OAuthV2/GenerateAccessToken dans Apigee Edge vérifie implicitement les identifiants du client. Normalement, dans une requête de jeton OAuthV2, les paramètres client_id et client_secret sont transmis dans En-tête d'autorisation, codé via l'autorisation de base HTTP (ces deux-points sont concaténés, puis codé en base64). La règle OAuthV2/GenerateAccessToken dans Apigee Edge décode cet en-tête et recherche client_id et vérifie que le client_secret transmis est valide pour cette client_id. Cela fonctionne si les identifiants sont connus d'Apigee Edge. En d'autres termes, Application de développeur stockée dans Apigee Edge qui contient un identifiant, qui contient lui-même le client_id et client_secret donnés.

Dans le cas où les informations d'identification du client ne doivent pas être validées par Apigee Edge, vous devez Concevez votre proxy d'API, avant qu'il ne génère un jeton, pour valider explicitement le client via une d'autres moyens. Ceci est souvent via une règle ServiceCallout qui se connecte à un point de terminaison distant de votre réseau.

D'une manière ou d'une autre, implicitement ou explicitement, vous devez vous assurer que le proxy d'API qui génère des jetons, valide d'abord les identifiants client. N'oubliez pas que la validation du client est indépendante de la génération du jeton d'accès. Vous pouvez configurer Apigee Edge pour les deux, ou de faire l'un ou l'autre, ou aucun.

Si vous souhaitez que la stratégie OAuthV2/GenerateAccessToken dans Apigee Edge pour valider le client les identifiants au magasin Edge, définissez l'élément <ExternalAuthorization> sur false dans la configuration de la règle, ou omettez-la complètement. Si vous souhaitez utiliser un service d'autorisation externe pour valider explicitement les identifiants client, définissez <ExternalAuthorization> sur true.

Même si Apigee Edge ne valide pas les informations d'identification du client, il est toujours nécessaire pour la client_id doit être connu et géré par Apigee Edge. Chaque jeton d'accès (access_token) dans Apigee Edge, que généré par Apigee Edge ou généré par un système externe, puis importé dans Apigee Edge. doit être associé à une application cliente - indiquée par client_id. Même dans le cas où la règle OAuthV2/GenerateAccessToken dans Apigee Edge ne validera pas que le client_id et client_secret, la stratégie vérifiera que client_id est valide, présent et non révoquée. Ainsi, comme étape de configuration préalable, vous devrez peut-être importer des client_id via le serveur Edge API d'administration.

Flux de stratégie pour OAuth tiers sur Apigee

Pour utiliser des jetons de systèmes OAuth tiers dans Apigee Edge, le flux de génération d'accès les jetons doivent suivre l'un des formats suivants.

Validation externe des identifiants client

ServiceCallout pour vérifier les identifiants du client entrant, et acquérir un jeton externe.
ExtractVariables ou une étape JavaScript pour extraire le jeton généré en externe à partir de la réponse.
AssignMessage pour définir la variable bien connue nommée oauth_external_authorization_status. La valeur doit être vraie pour indiquer que les identifiants du client sont valides.
OAuthV2/GenerateAccessToken avec l'élément <ExternalAuthorization> défini sur true et au moins l'une des valeurs <ExternalAccessToken>, <ExternalRefreshToken> ou <ExternalAuthorizationCode>.

Validation interne des identifiants client

ServiceCallout pour acquérir un jeton externe.
ExtractVariables ou une étape JavaScript pour extraire le jeton généré en externe à partir de la réponse.
OAuthV2/GenerateAccessToken avec l'élément <ExternalAuthorization> défini sur false et au moins l'une des valeurs <ExternalAccessToken>, <ExternalRefreshToken> ou <ExternalAuthorizationCode>.

Remarques sur la configuration du flux et des stratégies

Si vous souhaitez utiliser un système externe pour valider les identifiants client, il vous incombe de développer un flux de stratégies qui effectue les tâches nécessaires. Normalement, une règle ServiceCallout envoie les identifiants reconnus en externe au service d'authentification externe. Le service d'authentification externe renvoie généralement une réponse et, si les identifiants sont valides, un jeton d'accès.
Après le ServiceCallout, le proxy d'API doit analyser la réponse pour extraire l'état de validité, ainsi que le paramètre access_token généré de manière externe et éventuellement le paramètre refresh_token.
Dans la stratégie OAuthV2/GenerateAccessToken, définissez l'élément <StoreToken> sur true et l'élément <ExternalAuthorization> sur true ou false selon le cas.

Lorsque la stratégie OAuthV2/GenerateAccessToken s'exécute, elle lit la variable oauth_external_authorization_status. Si la variable est définie et que la valeur est true, Apigee Edge ne tente pas de valider les informations d'identification du client. Si la variable n'est pas défini ou la valeur n'est pas vraie, Apigee Edge tentera de valider le client identifiants de connexion.
La règle OAuthV2 comprend trois éléments qui vous permettent de spécifier les données externes à importer : <ExternalAccessToken>, <ExternalRefreshToken> et <ExternalAuthorizationCode>. Chacun de ces éléments accepte une variable de flux. La règle Edge lira cette variable pour trouver la un jeton d'accès, un jeton d'actualisation ou un code d'autorisation générés en externe. Il vous appartient de mettre en œuvre des stratégies et des logiques pour placer les jetons ou codes externes dans les variables appropriées.

Par exemple, la configuration suivante dans la stratégie OAuthV2 indique à Edge de rechercher le dans une variable de contexte nommée external_token.
```
<ExternalAccessToken>external_token</ExternalAccessToken>
```
Vous devez également disposer d'une étape précédente qui définit cette variable.
Concernant la définition de la variable oauth_external_authorization_status, une technique courante de définition de cette variable consiste à utiliser une stratégie AssignMessage avec l'élément AssignVariable, comme suit :
```
<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>
```
N'oubliez pas que cette stratégie doit précéder la stratégie OAuthV2 avec Operation = GenerateAccessToken.

Exemple de règle OAuthV2

La stratégie OAuthV2 suivante génère un jeton d'accès Apigee Edge étant donné qu'Edge trouve un la valeur du jeton dans la variable de flux 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>

Normalement, avec le client, vous devez fournir un en-tête "Basic Authentication" avec le client encodé et le code secret du client. Toutefois, dans ce cas, vous n'avez pas besoin de fournir ces en-tête. La règle s'attend toujours à ce que client_id soit présent dans la requête, et que la règle valide. Edge s'attend à ce que le client_id soit envoyé dans le cadre de des données du formulaire de demande, par exemple dans request.formparam.client_id.

En théorie, vous pouvez appliquer ce modèle avec n'importe quel service d'autorisation tiers OAuth2.