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

Mettre en œuvre le type d'attribution des identifiants client

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Avec le type d'attribution des identifiants client, une application envoie ses propres identifiants (l'ID et le code secret du client) à un point de terminaison sur Apigee Edge configuré pour générer un jeton d'accès. Si les identifiants sont valides, Edge renvoie un jeton d'accès à l'application cliente.

À propos de ce sujet

Cette rubrique propose une description générale du type d'attribution des identifiants client OAuth 2.0 et explique comment mettre en œuvre ce flux sur Apigee Edge.

Cas d'utilisation

En règle générale, ce type d'autorisation est utilisé lorsque l'application est également propriétaire de la ressource. Par exemple, une application peut avoir besoin d'accéder à un service de backend de stockage basé sur le cloud pour stocker et récupérer des données qu'elle utilise pour effectuer son travail, plutôt que des données appartenant spécifiquement à l'utilisateur final. Ce flux de type d'attribution se produit strictement entre une application cliente et le serveur d'autorisation. Un utilisateur final ne participe pas à ce flux de type de subvention.

Rôles

Les rôles spécifient les "acteurs" qui participent au flux OAuth. Voyons un aperçu rapide des rôles liés aux identifiants client pour illustrer le rôle d'Apigee Edge. Pour obtenir des informations complètes sur les rôles OAuth 2.0, consultez la spécification IETF OAuth 2.0.

Application cliente : application qui a besoin d'accéder aux ressources protégées de l'utilisateur. En règle générale, avec ce flux, l'application s'exécute sur le serveur plutôt que localement sur l'ordinateur portable ou l'appareil de l'utilisateur.
Apigee Edge - Dans ce flux, Apigee Edge est le serveur d'autorisation OAuth. Son rôle consiste à générer des jetons d'accès, à valider des jetons d'accès et à transmettre au serveur de ressources des requêtes autorisées pour des ressources protégées.
Serveur de ressources : service de backend qui stocke les données protégées pour lesquelles l'application cliente a besoin d'une autorisation d'accès. Si vous protégez des proxy API hébergés sur Apigee Edge, Apigee Edge est également le serveur de ressources.

Exemple de code

Vous trouverez un exemple de mise en œuvre complet du type d'octroi d'identifiants client sur GitHub. Consultez les ressources supplémentaires ci-dessous pour obtenir des liens vers d'autres exemples.

Schéma de flux

Le schéma de flux suivant illustre le flux d'identifiants client avec Apigee Edge en tant que serveur d'autorisation. En général, Edge est également le serveur de ressources dans ce flux, c'est-à-dire que les proxys d'API sont les ressources protégées.

Étapes dans le flux d'identifiants client

Voici un récapitulatif des étapes requises pour mettre en œuvre le type d'attribution de code d'identifiants client où Apigee Edge sert de serveur d'autorisation. N'oubliez pas qu'avec ce flux, l'application cliente présente simplement son ID client et son code secret. Si ils sont valides, Apigee Edge renvoie un jeton d'accès.

Condition préalable:l'application cliente doit être enregistrée auprès d'Apigee Edge pour obtenir l'ID et les clés secrètes du client. Pour en savoir plus, consultez la section Enregistrer des applications clientes.

1. Le client demande un jeton d'accès

Pour recevoir un jeton d'accès, le client utilise la méthode POST à partir d'un appel d'API à Edge avec les valeurs d'ID client et de secret client obtenus à partir d'une application de développeur enregistrée. De plus, le paramètre grant_type=client_credentials doit être transmis en tant que paramètre de requête. Toutefois, vous pouvez configurer la règle OAuthV2 afin qu'elle accepte ce paramètre dans l'en-tête ou le corps de la requête. Pour en savoir plus, consultez la stratégie OAuthV2.

Exemple :

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials&client_id=ns4fQc14Zg4hKFCNaSzArVuwszX95X&client_secret=ZIjFyTsNgQNyxI'

Remarque:Bien que vous puissiez transmettre les valeurs client_id et client_secret en tant que paramètres de requête comme indiqué ci-dessus, il est recommandé de les transmettre sous la forme d'une chaîne encodée au format URL en base64 dans l'en-tête Authorization. Pour ce faire, vous devez utiliser un outil ou un utilitaire d'encodage base64 pour encoder les deux valeurs ensemble avec un deux-points les séparant. Comme ceci : aBase64EncodeFunction(clientidvalue:clientsecret). Ainsi, l'exemple ci-dessus serait encodé comme suit:

result = aBase64EncodeFunction(ns4fQc14Zg4hKFCNaSzArVuwszX95X:ZIjFyTsNgQFAIpQLSdI) // Notez le signe deux-points qui séparent les deux valeurs.

Le résultat de l'encodage en base64 de la chaîne ci-dessus est le suivant : bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg==

Ensuite, effectuez la requête de jeton comme suit :

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg=='

2. Edge valide les identifiants

Notez que l'appel d'API est envoyé au point de terminaison /accesstoken. Ce point de terminaison est associé à une stratégie qui valide les identifiants de l'application. En d'autres termes, la stratégie compare les clés soumises avec celles créées par Apigee Edge lors de l'enregistrement de l'application. Pour en savoir plus sur les points de terminaison OAuth sur Edge, consultez la section Configurer des règles et des points de terminaison OAuth.

3. Edge renvoie une réponse

Si les informations d'identification sont correctes, Edge renvoie un jeton d'accès au client. Sinon, une erreur est renvoyée.

4. Le client appelle l'API protégée

Désormais, avec un jeton d'accès valide, le client peut effectuer des appels vers l'API protégée. Dans ce scénario, les requêtes sont adressées à Apigee Edge (le proxy) et Edge est responsable de la validation du jeton d'accès avant de transmettre l'appel d'API au serveur de ressources cible. Pour obtenir un exemple, consultez la section Appeler l'API protégée ci-dessous.

Configurer les flux et les règles

En tant que serveur d'autorisation, Edge traite les demandes de jetons d'accès. En tant que développeur d'API, vous devez créer un proxy avec un flux personnalisé pour gérer les requêtes de jeton, et ajouter et configurer une stratégie OAuthV2. Cette section explique comment configurer ce point de terminaison.

Configuration de flux personnalisé

Le moyen le plus simple d'afficher la configuration du flux du proxy d'API consiste à afficher la définition de flux XML. Voici un exemple de flux de proxy d'API conçu pour traiter une requête de jeton d'accès. Par exemple, lorsqu'une requête arrive et que le suffixe de chemin correspond à /accesstoken, la stratégie GetAccessToken est déclenchée. Consultez la page Configurer des points de terminaison et des règles OAuth pour obtenir un aperçu rapide de la procédure à suivre pour créer un flux personnalisé de ce type.

<Flows>
  <Flow name="GetAccessToken">
         <!-- This policy flow is triggered when the URI path suffix
         matches /oauth/accesstoken. Publish this URL to app developers 
         to use when obtaining an access token using an auth code   
         -->
    <Condition>proxy.pathsuffix == "/oauth/accesstoken"</Condition>
    <Request>
        <Step><Name>GetAccessToken</Name></Step>
    </Request>
  </Flow>
</Flows>

Configurer le flux avec une règle

Vous devez associer une règle au point de terminaison, comme suit : Pour obtenir un bref aperçu des étapes nécessaires à l'ajout d'une règle OAuthV2 à un point de terminaison proxy, consultez la page Configurer des points de terminaison et des règles OAuth.

Obtenir un jeton d'accès

Cette règle est associée au chemin d'accès /accesstoken. Il utilise la stratégie OAuthV2 avec l'opération GenerateAccessToken spécifiée.

<OAuthV2 name="GetAccessToken">
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn>3600000</ExpiresIn>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GenerateResponse/>
</OAuthV2>

L'appel d'API permettant d'obtenir le jeton d'accès est une requête POST, et inclut un en-tête d'autorisation avec client_id encodé en base64 + client+secret et paramètre de requête "grant_type=client_credentials". Il peut également inclure des paramètres facultatifs pour la portée et l'état. Exemple :

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVgT1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ'

Associer la règle de vérification du jeton d'accès

Pour protéger votre API avec la sécurité OAuth 2.0, vous devez ajouter une stratégie OAuthV2 avec l'opération VerifyAccessToken. Cette règle vérifie que les requêtes entrantes disposent d'un jeton d'accès valide. Si le jeton est valide, Edge traite la demande. Si elle n'est pas valide, Edge renvoie une erreur. Pour connaître la procédure de base, consultez Valider des jetons d'accès.

<OAuthV2 async="false" continueOnError="false" enabled="true" name="VerifyAccessToken">
    <DisplayName>VerifyAccessToken</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <SupportedGrantTypes/>
    <GenerateResponse enabled="true"/>
    <Tokens/>
</OAuthV2>

Appeler l'API protégée

Pour appeler une API protégée par la sécurité OAuth 2.0, vous devez présenter un jeton d'accès valide. Le format correct consiste à inclure le jeton dans un en-tête "Authorization", comme suit. Notez que le jeton d'accès est également appelé "jeton de support".

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

Consultez également la section Envoyer un jeton d'accès.

Autres ressources

Apigee propose une formation en ligne pour les développeurs d'API, dont un cours sur la sécurité des API, qui inclut OAuth.
Stratégie OAuthV2 : comprend de nombreux exemples indiquant comment envoyer des requêtes au serveur d'autorisation et comment configurer la stratégie OAuthV2.