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

Mise en œuvre du type d'attribution de mot de passe

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

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 Edge. Un serveur d'identité valide les identifiants et, s'ils sont valides, Edge 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 Edge.

Exemples utiles

Demander un jeton d'accès : Type d'attribution de mot de passe Cette page explique comment construire une requête de jeton, configurer la stratégie OAuthV2 pour le type d'attribution du mot de passe et configurer un point de terminaison pour la stratégie dans Edge.
oauth-validate-key-secret : exemple de proxy dans GitHub que vous pouvez déployer et tester sur Edge. 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 Edge 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 Edge sert de serveur d'autorisation.

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.

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 Edge

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 Edge.

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 des détails sur l'en-tête d'authentification de base requis, consultez la section concernant l'attribution de mots de passe sur la page Demander des jetons d'accès et des codes d'autorisation.

3. Edge 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. Edge 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, Edge poursuit le traitement de la requête. Sinon, Edge interromp 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 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. 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