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

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

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

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

À propos de ce sujet

Cette rubrique présente 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. Passons rapidement en revue les rôles liés aux informations d'identification du client pour illustrer la place 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 système d'authentification Google Cloud. 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 suivant illustre le flux des identifiants du client avec Apigee Edge en tant que le serveur d'autorisation. En général, Edge est également le serveur de ressources dans ce flux, c'est-à-dire 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 client et les clés secrets 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:Vous pouvez transmettre les valeurs client_id et client_secret sous forme de requête comme indiqué ci-dessus, nous vous conseillons de les transmettre sous forme de chaîne encodée au format URL base64 l'en-tête "Authorization". Pour ce faire, vous devez utiliser un outil ou un utilitaire d'encodage base64 pour encoder les deux valeurs avec deux-points les séparant par un deux-points. Comme ceci: aBase64EncodeFunction(valeurduclient:secretclient). Ainsi, l'exemple ci-dessus serait encodé comme ceci:

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 la 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, elle compare les valeurs par celles qu'Apigee Edge a créées lors de l'enregistrement de l'application. Si vous souhaitez Pour en savoir plus sur les points de terminaison OAuth sur Edge, voir Configuration d'OAuth points de terminaison et règles.

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. Pour exemple, lorsqu'une requête arrive et que le suffixe du chemin correspond à /accesstoken, la méthode GetAccessToken est déclenchée. Reportez-vous à la page Configuration d'OAuth points de terminaison et règles pour obtenir un aperçu des étapes nécessaires à la création d'un flux personnalisé comme ceci.

<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 pour obtenir le jeton d'accès est un POST et inclut un en-tête Authorization 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.