Cette page s'applique à Apigee et à Apigee hybrid.
Consultez la documentation d'Apigee Edge.
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 configuré pour générer un jeton d'accès. Si les identifiants sont valides, Apigee renvoie un jeton d'accès à l'application cliente.
À propos de ce thème
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.
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. Examinons rapidement les rôles d'identifiants client pour vous aider à comprendre celui d'Apigee. 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 : dans ce flux, Apigee 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 proxys d'API hébergés sur Apigee, Apigee 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 servant de serveur d'autorisation. En général, Apigee 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ésumé de la procédure à suivre pour mettre en œuvre le type d'attribution de code d'identifiants client dans lequel Apigee sert de serveur d'autorisation. N'oubliez pas que avec ce flux, l'application cliente présente simplement son ID client et son code secret. S'ils sont valides, Apigee renvoie un jeton d'accès.
Condition préalable : l'application cliente doit être enregistrée auprès d'Apigee pour obtenir l'ID client 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 d'un appel d'API à Apigee avec les valeurs de l'ID client et du code secret du client obtenus à partir d'une application de développeur enregistrée (dans cet exemple, les valeurs sont encodées en base64 et transmises dans l'en-tête Authorization). 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 section sur la règle OAuthV2.
Exemple :
curl -H "Content-Type: application/x-www-form-urlencoded" \ -H "Authorization: Basic c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ" \ -X POST "https://apitest.acme.com/oauth/token" \ -d "grant_type=client_credentials"
Consultez également Utiliser le type d'octroi d'identifiants client.
2. Apigee valide les identifiants
Notez que l'appel d'API est envoyé au point de terminaison /oauth/token. Ce point de terminaison est associé à une stratégie qui valide les identifiants de l'application. Autrement dit, la règle compare les clés envoyées à celles créées par Apigee lors de l'enregistrement de l'application. Si vous souhaitez en savoir plus sur les points de terminaison OAuth sur Apigee, consultez la page Configurer des points de terminaison et des règles OAuth.
3. Apigee renvoie une réponse
Si les identifiants sont corrects, Apigee 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 envoyées à Apigee (le proxy) et Apigee assure 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, Apigee 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 à /oauth/token, la règle 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/token. Publish this URL to app developers
to use when obtaining an access token using an auth code
-->
<Condition>proxy.pathsuffix == "/oauth/token"</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 /oauth/token. 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 le champ d'application 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, Apigee traite la requête. S'il n'est pas valide, Apigee 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.