Vous consultez la documentation Apigee Edge.
Accédez à la
documentation**Apigee X**. info
Avec le type d'attribution des identifiants client, une application envoie ses propres identifiants (l'ID client 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 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'attribution 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 d'attribution.
Rôles
Les rôles spécifient les "acteurs" qui participent au flux OAuth. Examinons rapidement les rôles d'identifiants client pour vous aider à comprendre celui 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 servant de serveur d'autorisation. En général, Edge est le serveur de ressources de ce flux. En d'autres termes, 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.
Conditions préalables : l'application cliente doit être enregistrée auprès d'Apigee Edge pour obtenir l'ID client et les clés secrètes du client. Pour en savoir plus, consultez la section Enregistrer des applications clientes pour plus de détails.
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 de requête ou le corps de la requête. Pour en savoir plus, consultez la section sur la règle 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 en tant que chaîne encodée en base64 dans l'en-tête "Authorization". Pour ce faire, vous devez utiliser un outil ou un utilitaire d'encodage en base64 pour encoder les deux valeurs ensemble, en les séparant par un signe deux-points. Par exemple : 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. Autrement dit, la stratégie compare les clés envoyées à celles créées par Apigee Edge lors de l'enregistrement de l'application. Si vous souhaitez en savoir plus sur les points de terminaison OAuth sur Edge, consultez la page Configurer des points de terminaison et des stratégies OAuth.
3. Edge renvoie une réponse
Si les identifiants sont corrects, 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 Appeler l'API protégée ci-dessous.
Configurer les flux et les règles
En tant que serveur d'autorisation, Edge traite les requêtes 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 du chemin correspond à /accesstoken, la stratégie GetAccessToken est déclenchée. Consultez la page Configurer des points de terminaison et des stratégies OAuth pour obtenir un aperçu rapide des étapes nécessaires à la création d'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 stratégie
Vous devez associer une stratégie au point de terminaison, comme suit : Pour obtenir un bref aperçu des étapes nécessaires à l'ajout d'une stratégie OAuthV2 à un point de terminaison proxy, consultez la page Configurer des points de terminaison et des stratégies OAuth.
Obtenir un jeton d'accès
Cette stratégie 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 une requête POST qui inclut un en-tête "Authorization" avec client_id + client+secret encodé en base64 et le 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 stratégie vérifie que les requêtes entrantes disposent d'un jeton d'accès valide. Si le jeton est valide, Edge traite la requête. Sinon, 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.