Cette page s'applique à Apigee et à Apigee hybrid.
Consultez la documentation d'Apigee Edge.
Le type d'attribution de mot de passe du propriétaire de la ressource (ou "mot de passe") est principalement utilisé lorsque l'application est pleinement approuvée. Dans cette configuration, l'utilisateur fournit ses identifiants de serveur de ressources (nom d'utilisateur/mot de passe) à l'application cliente, qui l'envoie dans une requête de jeton d'accès à Apigee. Un serveur d'identité valide les identifiants et, s'ils sont valides, Apigee poursuit la transmission d'un jeton d'accès et le renvoie à l'application.
À propos de ce thème
Cet article présente une description générale et une vue d'ensemble du flux d'attribution de mots de passe des propriétaires de ressources OAuth 2.0, et explique comment mettre en œuvre ce flux sur Apigee.
Exemples utiles
- Utiliser le type d'attribution du mot de passe : Explique comment construire une demane de jeton, configurer la règle OAuthV2 pour le type d'attribution du mot de passe et configurer un point de terminaison pour la règle dans Apigee.
- oauth-validate-key-secret : exemple de proxy dans GitHub que vous pouvez déployer et tester sur Apigee. Il s'agit d'un exemple de bout en bout incluant le type d'attribution de mot de passe. Il illustre une bonne pratique qui consiste à authentifier les identifiants de l'application cliente (clé/secret) avant de les envoyer à un fournisseur d'identité.
Vidéo
Vidéo : regardez cette vidéo sur la mise en œuvre du type d'attribution de mot de passe.
Cas d'utilisation
Ce type d'attribution est destiné aux applications pleinement approuvées ou privilégiées, car l'utilisateur doit transmettre ses identifiants de serveur de ressources à l'application. En règle générale, l'application fournit un écran de connexion sur lequel l'utilisateur saisit ses identifiants.
Schéma de flux
Le schéma de flux suivant illustre le flux de type de mot de passe du propriétaire de la ressource où Apigee sert de serveur d'autorisation.
Conseil : Pour afficher une version plus grande de ce schéma, faites un clic droit dessus et ouvrez-le dans un nouvel onglet, ou enregistrez-le et ouvrez-le dans une visionneuse d'images.
Étapes du flux de type d'attribution de mot de passe
Voici un résumé des étapes à suivre pour mettre en œuvre le type d'attribution de mot de passe où Apigee sert de serveur d'autorisation.
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. L'utilisateur lance le flux et saisit les identifiants.
Lorsque l'application doit accéder aux ressources protégées de l'utilisateur (par exemple, lorsque celui-ci clique sur un bouton dans l'application), il est redirigé vers un formulaire de connexion.
2. L'application demande un jeton d'accès à Apigee
L'application envoie une requête de jeton d'accès, y compris les identifiants de l'utilisateur, à un point de terminaison GenerateAccessToken sur Apigee.
Voici un exemple de requête POST incluant les paramètres requis pour ce type d'autorisation :
$ curl -i \ -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \ -d 'grant_type=password&username=the-user-name&password=the-users-password' \ https://docs-test.apigee.net/oauth/token
Vous pouvez également exécuter cette commande de la façon suivante, en utilisant l'option -u dans curl afin de créer l'en-tête d'authentification de base encodée en base64.
$ curl -i \ -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ -u sqH8ooHexTz8C02IX9ORo6rhgq1iSrAl:Z4ljtJdneBOjPMAU \ -d 'grant_type=password&username=the-user-name&password=the-users-password' \ https://docs-test.apigee.net/oauth/token
(Chacune de ces commandes doit apparaître sur une seule ligne.)
Les identifiants utilisateur sont contenus dans les paramètres du formulaire, tandis que les identifiants client sont encodés dans l'en-tête d'authentification de base HTTP. Pour obtenir une description détaillée de cet appel d'API, y compris les détails de l'en-tête d'authentification de base requis, consultez la section sur l'attribution de mots de passe dans Obtenir des jetons OAuth 2.0.
3. Apigee valide l'application cliente
Avant d'envoyer le nom d'utilisateur et le mot de passe de l'utilisateur à un fournisseur d'identité, Edge doit savoir que l'application cliente effectuant la demande est valide et approuvée. Pour ce faire, vous pouvez utiliser l'authentification par clé API sur l'appel d'API. Dans certains cas, vous souhaiterez peut-être valider la clé et le code secret du client. Vous trouverez un exemple de proxy illustrant cette autre méthode dans le dépôt api-platform-samples sur GitHub.
4. Apigee traite les identifiants de connexion
Une fois l'application cliente validée, vous pouvez utiliser une règle d'appel de service ou JavaScript pour appeler le service d'identité, en envoyant les identifiants de l'utilisateur. Par exemple, il peut s'agir d'un service LDAP ou de tout service que vous souhaitez utiliser pour valider les identifiants. Pour en savoir plus sur ces règles, consultez les pages Règles d'extraction des variables et Règles JavaScript.
Si le service d'identité valide les identifiants et renvoie une réponse 200, Apigee poursuit le traitement de la requête. Sinon, Apigee interrompt le traitement et renvoie une erreur à l'application cliente.
5. La règle OAuthV2 s'exécute
Si les identifiants sont valides, l'étape de traitement suivante consiste à exécuter une règle OAuthV2 configurée pour le type d'attribution de mot de passe. Voici un exemple : Les éléments <UserName> et <PassWord> sont obligatoires. Vous pouvez les récupérer à partir des variables de flux enregistrées avec la règle ExtractVariables. Pour obtenir des informations détaillées sur cette règle, consultez la section Règles OAuthV2.
<OAuthV2 name="GetAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>360000000</ExpiresIn>
<SupportedGrantTypes>
<GrantType>password</GrantType>
</SupportedGrantTypes>
<GrantType>request.queryparam.grant_type</GrantType>
<UserName>login</UserName>
<PassWord>password</PassWord>
<GenerateResponse/>
</OAuthV2>
Si cette règle aboutit, une réponse est renvoyée au client contenant un jeton d'accès. La réponse est au format JSON. Par exemple : Notez que access_token est l'un des éléments :
{
"issued_at": "1420258685042",
"scope": "READ",
"application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
"refresh_token_issued_at": "1420258685042",
"status": "approved",
"refresh_token_status": "approved",
"api_product_list": "[PremiumWeatherAPI]",
"expires_in": "1799",
"developer.email": "tesla@weathersample.com",
"organization_id": "0",
"token_type": "BearerToken",
"refresh_token": "IFl7jlijYuexu6XVSSjLMJq8SVXGOAAq",
"client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
"access_token": "I6daIgMSiUgYX1K2qgQWPi37ztS6",
"organization_name": "docs",
"refresh_token_expires_in": "0",
"refresh_count": "0"
}
6. Le client appelle l'API protégée
Maintenant qu'il dispose d'un code d'accès valide, le client peut appeler 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. Les jetons d'accès sont transmis dans un en-tête d'autorisation. Exemple :
$ curl -H "Authorization: Bearer I6daIgMSiUgYX1K2qgQWPi37ztS6
" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282