Effectuer une requête vers votre API à l’aide du flux Resource Owner Password

Découvrez comment effectuer une requête vers votre propre API depuis des applications hautement fiables à l’aide du flux Resource Owner Password.

Ce tutoriel vous aidera à appeler votre propre API à l’aide du Resource Owner Password Flow. Si vous souhaitez comprendre le fonctionnement de ce flux et pourquoi l’utiliser, consultez Resource Owner Password Flow.

Comme le flux Resource Owner Password (ROP) exige que l’application gère le mot de passe de l’utilisateur, il ne doit pas être utilisé par des clients tiers.

Auth0 permet à votre application d’implémenter facilement le Resource Owner Password Flow (parfois appelé Resource Owner Password Grant ou ROPG) à l’aide de l’Authentication API. Lisez la suite pour savoir comment appeler directement notre API.

​

Prérequis

Avant de commencer ce tutoriel :

• Enregistrez votre Application auprès d’Auth0.

  • Sélectionnez Regular Web Apps comme Application Type.
  • Ajoutez {https://yourApp/callback} comme Allowed Callback URL. Ce champ ne peut pas rester indéfini, sinon un message d’erreur sera renvoyé.
  • Assurez-vous que les Grant Types de votre Application incluent Password. Pour savoir comment faire, consultez Mettre à jour les type d’octroi.
  • Si vous voulez que votre Application puisse utiliser des jetons d’actualisation, assurez-vous que les Grant Types de l’Application incluent jeton d’actualisation. Pour savoir comment faire, consultez Mettre à jour les type d’octroi. Pour en savoir plus sur les jetons d’actualisation, consultez jetons d’actualisation.

• Enregistrez votre API auprès d’Auth0

  • Si vous voulez que votre API reçoive des jetons d’actualisation pour pouvoir obtenir de nouveaux jetons lorsque les précédents expirent, activez Allow Offline Access.

• Configurez une connexion

  • Assurez-vous que votre connexion peut authentifier les utilisateurs avec un nom d’utilisateur et un mot de passe (par exemple, les connexions de base de données, ou les connexions d’entreprise AD/LDAP, ADFS ou Azure Active Directory).

• Mettez à jour ou désactivez les rules afin qu’elles n’affectent que des connexions précises. Si vous obtenez une erreur access_denied en testant le Password Owner Resource Grant, cela peut être dû à une règle de contrôle d’accès.

​

Étapes

1. Configurer le tenant:Définissez la connexion par défaut du tenant.
2. Obtenir des jetons: Échangez votre code d’autorisation contre des jetons.
3. Appeler l’API: Utilisez le jeton d’accès récupéré pour appeler votre API.
4. Actualiser les jetons: Utilisez un jeton d’actualisation pour obtenir de nouveaux jetons lorsque les jetons existants expirent.

Facultatif : Explorer des exemples de cas d’utilisation

Facultatif : Configurer la prise en charge des realms

Facultatif : Configurer MFA

Facultatif : Configurer la protection contre les attaques

​

Configurer le tenant

Le Resource Owner Password Flow s’appuie sur une connexion capable d’authentifier les utilisateurs avec un nom d’utilisateur et un mot de passe. Vous devez donc définir la connexion par défaut du tenant.

1. Accédez à Auth0 Dashboard > Tenant Settings, puis faites défiler la page jusqu’au paramètre Default Directory.
2. Entrez le nom de la connexion que vous souhaitez utiliser. Assurez-vous qu’elle permet d’authentifier les utilisateurs avec un nom d’utilisateur et un mot de passe.

​

Demander des jetons

Pour appeler votre API, vous devez d’abord obtenir les identifiants de l’utilisateur, généralement à l’aide d’un formulaire interactif. Une fois que votre application a ces identifiants, vous devez les échanger contre des jetons. Pour ce faire, vous devez envoyer une requête POST à l’URL du jeton.

​

Exemple de requête POST vers l’URL du jeton

Paramètres

Nom du paramètre	Description
grant_type	Définissez ce paramètre sur password.
username	Le nom d’utilisateur saisi par l’utilisateur.
password	Le mot de passe saisi par l’utilisateur.
client_id	L’ID client de votre application. Vous trouverez cette valeur dans les Paramètres de l’application.
client_assertion	Un JWT contenant une assertion signée avec les informations d’authentification de votre application. Obligatoire lorsque Private Key JWT est votre méthode d’authentification de l’application.
client_assertion_type	La valeur est urn:ietf:params:oauth:client-assertion-type:jwt-bearer. Obligatoire lorsque Private Key JWT est la méthode d’authentification de l’application.
client_secret	Le secret client de votre application. Obligatoire lorsque Client Secret est la méthode d’authentification de l’application et que, dans les Paramètres de l’application, la valeur est Post ou Basic. Si votre application n’est pas hautement fiable (par exemple, une SPA), ne définissez pas ce paramètre.
audience	L’audience du jeton, c’est-à-dire votre API. Vous la trouverez dans le champ Identifiant de l’onglet des paramètres de votre API.
scope	Indique les scopes pour lesquelles vous souhaitez demander une autorisation, ce qui détermine quels claims (ou attributs utilisateur) vous voulez voir renvoyés. Elles doivent être séparées par un espace. Vous pouvez demander n’importe laquelle des scopes OpenID Connect (OIDC) standard concernant les utilisateurs, comme profile ou email, des claims personnalisés conformes à un format avec espace de noms, ou tout scope pris en charge par l’API cible (par ex. read:contacts). Incluez offline_access pour obtenir un Refresh Token (assurez-vous que le champ Allow Offline Access est activé dans les Paramètres de l’application).

​

Réponse

Si tout se passe bien, vous recevrez une réponse HTTP 200 avec un payload contenant les valeurs access_token, refresh_token, id_token, token_type et expires_in :

{
  "access_token": "eyJz93a...k4laUWw",
  "refresh_token": "GEbRxBN...edjnXbL",
  "id_token": "eyJ0XAi...4faeEoQ",
  "token_type": "Bearer",
  "expires_in": 36000
}

Validez vos jetons avant de les enregistrer. Pour savoir comment faire, consultez Valider le jeton d’identité et Valider les jetons d’accès.

Les jetons d’actualisation doivent être stockés de manière sécuritaire, puisqu’ils permettent à un utilisateur de rester authentifié pratiquement indéfiniment.

Flux Resource Owner Password et scopes standard

Comme le fait de fournir un mot de passe donne un accès complet, tout échange basé sur un mot de passe donne accès à tous les scopes. Par exemple, si vous n’incluez aucun scope d’API dans la requête, tous les scopes d’API seront inclus dans le jeton d’accès. De même, si vous incluez seulement le scope openid dans la requête, tous les scopes OpenID Connect standard de openid seront renvoyés. Dans ces cas, le paramètre scope sera inclus dans la réponse et énumérera les scopes émis.

Obtenir les informations de l’utilisateur sans jeton d’identité

Si vous avez besoin des informations de l’utilisateur, incluez la portée openid dans votre requête. Si l’API utilise RS256 comme algorithme de signature, le jeton d’accès inclura /userinfo comme audience valide, ce qui signifie que vous pouvez l’utiliser pour appeler le point de terminaison UserInfo et récupérer les claims de l’utilisateur.

​

Appeler l’API

Pour appeler votre API, l’application doit transmettre le jeton d’accès récupéré comme jeton Bearer dans l’en-tête Authorization de votre requête HTTP.

​

Jetons d’actualisation

Vous avez déjà reçu un jeton d’actualisation si vous suivez ce tutoriel et avez effectué les étapes suivantes :

• configuré votre API pour autoriser l’accès hors ligne
• inclus le scope offline_access lorsque vous avez lancé la requête d’authentification au moyen du point de terminaison authorize.

Vous pouvez utiliser le jeton d’actualisation pour obtenir un nouveau jeton d’accès. En général, un utilisateur n’a besoin d’un nouveau jeton d’accès qu’après l’expiration du précédent ou lorsqu’il accède à une nouvelle ressource pour la première fois. Ce n’est pas une bonne pratique d’appeler le point de terminaison pour obtenir un nouveau jeton d’accès chaque fois que vous faites une requête à une API, et Auth0 applique des limites de taux qui restreignent le nombre de requêtes vers ce point de terminaison pouvant être exécutées avec le même jeton à partir de la même adresse IP.

Pour actualiser votre jeton, faites une requête POST au point de terminaison /oauth/token dans l’Authentication API, en utilisant grant_type=refresh_token.

​

Exemple de requête POST vers l’URL du jeton

Paramètres

Nom du paramètre	Description
grant_type	Définissez cette valeur sur refresh_token.
client_id	Le Client ID de votre application. Vous trouverez cette valeur dans les paramètres de l’application.
refresh_token	Le refresh token à utiliser.
scope	(facultatif) Liste des autorisations de scope demandées, séparées par des espaces. Si elle n’est pas envoyée, les scopes d’origine seront utilisés; sinon, vous pouvez demander un ensemble réduit de scopes. Notez que cette valeur doit être encodée dans l’URL.

​

Réponse

Si tout se passe bien, vous recevrez une réponse HTTP 200 avec une charge utile contenant un nouvel access_token, sa durée de validité en secondes (expires_in), les valeurs scope accordées et token_type.

{
  "access_token": "eyJ...MoQ",
  "expires_in": 86400,
  "scope": "openid offline_access",
  "token_type": "Bearer"
}

Validez vos jetons avant de les stocker. Pour savoir comment faire, consultez valider le jeton d’identité et Valider les jetons d’accès.

​

Exemples de scénarios d’utilisation

​

Personnaliser les jetons

Vous pouvez utiliser Actions pour modifier les scopes renvoyés dans les jetons d’accès et/ou ajouter des claims aux jetons d’accès et aux jetons ID. (Pour en savoir plus sur Actions, consultez Auth0 Actions.) Pour ce faire, ajoutez l’Action suivante, qui s’exécutera après l’authentification de l’utilisateur :

exports.onExecutePostLogin = async (event, api) => {
  // Ajouter des claims personnalisés au jeton d'accès et au jeton d'identité
  api.accessToken.setCustomClaim('https://foo/bar', 'value');
  api.idToken.setCustomClaim('https://fiz/baz', 'some other value');

  // Modifier le scope du jeton d'accès
  api.accessToken.addScope('foo');
  api.accessToken.addScope('bar');
};

Les scopes seront disponibles dans le jeton une fois l’Action exécutée.

Auth0 renvoie les informations de profil dans un format structuré de claim, comme le définit la spécification OpenID Connect (OIDC). Cela signifie que les claims personnalisés ajoutés aux jetons d’identité ou aux jetons d’accès doivent respecter certaines directives et restrictions afin d’éviter d’éventuels conflits.

​

Configurer la prise en charge des realms

Auth0 fournit un grant d’extension offrant une fonctionnalité semblable à celle du grant Resource Owner Password, mais qui vous permet de conserver des annuaires d’utilisateurs distincts (correspondant à des connexions distinctes) et de préciser lequel utiliser pendant le flux.

Pour utiliser cette variation, vous devez :

• Définir le paramètre de requête grant_type sur http://auth0.com/oauth/grant-type/password-realm.
• Envoyer un paramètre de requête supplémentaire nommé realm et le définir sur le nom du realm auquel l’utilisateur appartient. Par exemple, si vous avez configuré une connexion de base de données pour des employés internes nommée employees et que votre utilisateur en fait partie, définissez realm sur employees.

Connexions utilisées comme realms

Toute connexion qui prend en charge l’authentification active peut être configurée comme un realm, y compris les connexions de base de données, les connexions sans mot de passe, ainsi que les connexions d’entreprise AD/LDAP, ADFS et Azure Active Directory.

​

Configurer l’authentification multifacteur

Si vous devez utiliser le flux Resource Owner Password, mais que vous avez besoin d’une authentification plus robuste, vous pouvez ajouter l’authentification multifacteur (MFA). Pour savoir comment faire, consultez S’authentifier à l’aide du flux Resource Owner Password avec l’authentification multifacteur.

​

Configurer la protection contre les attaques

Lorsque vous utilisez le Resource Owner Password Flow avec la protection contre les attaques par force brute, certaines fonctionnalités de la protection contre les attaques peuvent ne pas fonctionner correctement. Il est toutefois possible d’éviter certains problèmes courants. Pour en savoir plus, consultez Avoid Common Issues with Resource Owner Password Flow and Attack Protection.

​

En savoir plus

• Cadre d’autorisation OAuth 2.0
• Protocole OpenID Connect
• Jetons