Appeler votre API à l’aide du flux de mot de passe du propriétaire de la ressource

Découvrez comment appeler votre propre API depuis des applications hautement fiables à l’aide du flux de mot de passe du propriétaire de la ressource.

Ce tutoriel vous aidera à appeler votre propre API à l’aide du flux de mot de passe du propriétaire de la ressource. Si vous souhaitez comprendre le fonctionnement de ce flux et pourquoi vous devriez l’utiliser, consultez Flux de mot de passe du propriétaire de la ressource.

Comme le flux de mot de passe du propriétaire de la ressource (ROP) exige que l’application gère le mot de passe de l’utilisateur, il ne doit pas être utilisé par des applications tierces.

Auth0 permet à votre application d’implémenter facilement le flux de mot de passe Resource Owner (parfois appelé octroi par mot de passe du propriétaire de la ressource ou ROPG) à l’aide de l’Authentication API. Continuez votre lecture pour découvrir comment appeler directement notre API.

​

Prérequis

Avant de commencer ce tutoriel :

• Enregistrez votre application auprès d’Auth0.

  • Sélectionnez un Application Type de Regular Web Apps.
  • Ajoutez une Allowed Callback URL de {https://yourApp/callback}. Ce champ ne peut pas être laissé vide, sinon un message d’erreur sera renvoyé.
  • Assurez-vous que les Grant Types de votre application incluent Password. Pour savoir comment faire, consultez Update Grant Types.
  • Si vous souhaitez que votre application puisse utiliser des Jetons d’actualisation, assurez-vous que les Grant Types de l’application incluent Refresh Token. Pour savoir comment faire, consultez Update Grant Types. Pour en savoir plus sur les Jetons d’actualisation, consultez Refresh Tokens.

• Enregistrez votre API auprès d’Auth0

  • Si vous souhaitez que votre API puisse recevoir des Jetons d’actualisation afin d’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 à l’aide d’un nom d’utilisateur et d’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 d’entreprise).

• Mettez à jour ou désactivez toutes les Rules afin qu’elles ne s’appliquent qu’à des connexions spécifiques. Si vous obtenez une erreur access_denied pendant le test du Password Owner Resource Grant, cela pourrait être dû à une règle de contrôle d’accès.

​

Étapes

1. Configurer le locataire:Définissez la connexion par défaut du locataire.
2. Demander des jetons: Échangez votre code d’autorisation contre des jetons.
3. Appeler l’API: Utilisez le Jeton d’accès obtenu pour appeler votre API.
4. Actualiser les jetons: Utilisez un Jeton d’actualisation pour demander de nouveaux jetons lorsque les jetons actuels expirent.

Facultatif : Explorer des exemples de cas d’utilisation

Facultatif : Configurer la prise en charge du realm

Facultatif : Configurer la MFA

Facultatif : Configurer la protection contre les attaques

​

Configurer le locataire

Le flux de mot de passe du propriétaire de la ressource repose sur une connexion capable d’authentifier les utilisateurs au moyen d’un nom d’utilisateur et d’un mot de passe; vous devez donc définir la connexion par défaut du locataire.

1. Accédez à Auth0 Dashboard > Paramètres du locataire, puis faites défiler la page jusqu’au paramètre Default Directory.
2. Saisissez le nom de la connexion que vous souhaitez utiliser. Assurez-vous qu’elle peut authentifier les utilisateurs au moyen d’un nom d’utilisateur et d’un mot de passe.

​

Obtenir des jetons

Pour appeler votre API, vous devez d’abord obtenir les identifiants de l’utilisateur, généralement au moyen d’un formulaire interactif. Une fois que votre application dispose de 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

Parameter Name	Description
grant_type	Définissez cette valeur 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 identifiants de votre application. Obligatoire lorsque JWT à clé privée est la méthode d’authentification de votre application.
client_assertion_type	La valeur est urn:ietf:params:oauth:client-assertion-type:jwt-bearer. Obligatoire lorsque JWT à clé privée est la méthode d’authentification de l’application.
client_secret	Le Secret client de votre application. Obligatoire lorsque Secret client est la méthode d’authentification de l’application. Dans les paramètres de l’application, cette 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, qui correspond à votre API. Vous la trouverez dans le champ Identifiant de l’onglet des paramètres de votre API.
scope	Indique les scopes pour lesquels vous souhaitez demander une autorisation, ce qui détermine quelles claims (ou quels attributs utilisateur) seront renvoyés. Ils doivent être séparés par une espace. Vous pouvez demander n’importe lequel des scopes OpenID Connect (OIDC) standards concernant les utilisateurs, comme profile ou email, des custom claims conformes à un format avec espace de noms, ou tout scope pris en charge par l’API cible (par exemple, read:contacts). Incluez offline_access pour obtenir un Jeton d’actualisation (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 les ID Tokens et Valider les jetons d’accès.

Les jetons d’actualisation doivent être stockés de façon sécurisée, puisqu’ils permettent à un utilisateur de rester authentifié pratiquement indéfiniment.

Flux de mot de passe du propriétaire de la ressource et scopes standard

Comme la fourniture d’un mot de passe donne un accès complet, tout échange fondé 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 seront renvoyés. Dans ces cas, le paramètre scope sera inclus dans la réponse et listera les scopes émis.

Obtenir les renseignements de l’utilisateur sans ID Token

Si vous avez besoin des renseignements de l’utilisateur, incluez le scope 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é dans l’en-tête Authorization de sa requête HTTP en tant que jeton Bearer.

​

Jetons d’actualisation

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

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

Vous pouvez utiliser le Jeton d’actualisation pour obtenir un nouveau jeton d’accès. Habituellement, 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. Il est déconseillé d’appeler le point de terminaison pour obtenir un nouveau jeton d’accès chaque fois que vous appelez une API, et Auth0 applique des limites de débit qui limiteront le nombre de requêtes au point de terminaison pouvant être exécutées avec le même jeton à partir de la même adresse IP.

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

​

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

Paramètres

Nom du paramètre	Description
grant_type	Définissez cette valeur sur refresh_token.
client_id	L’ID client de votre application. Vous trouverez cette valeur dans les paramètres de l’application.
refresh_token	Le jeton d’actualisation à utiliser.
scope	(facultatif) Une liste des scopes demandés, séparés par des espaces. Si cette valeur 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 pour être utilisée dans une URL.

​

Réponse

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

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

Validez vos jetons avant de les enregistrer. Pour savoir comment faire, consultez Valider les ID tokens et Valider les jetons d’accès.

​

Exemples de cas d’utilisation

​

Personnaliser les jetons

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

exports.onExecutePostLogin = async (event, api) => {
  // Ajouter des revendications personnalisées au jeton d'accès et à l'ID Token
  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 claims, tel que défini par la spécification OpenID Connect (OIDC). Cela signifie que les claims personnalisées ajoutées aux ID tokens ou aux jetons d’accès doivent respecter les directives et les restrictions afin d’éviter d’éventuelles collisions.

​

Configurer la prise en charge des realms

Auth0 fournit un octroi d’extension offrant une fonctionnalité semblable à celle de l’octroi Resource Owner Password, tout en vous permettant de conserver des répertoires d’utilisateurs distincts (qui correspondent à des connexions distinctes) et de préciser lequel utiliser durant le flux.

Pour utiliser cette variante, 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 appelé realm et lui attribuer le nom du realm auquel l’utilisateur appartient. Par exemple, si vous avez configuré une connexion de base de données pour les employés internes nommée employees, et que votre utilisateur en fait partie, définissez realm sur employees.

Connexions en tant que 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 Passwordless et les connexions d’entreprise AD/LDAP, ADFS et Azure Active Directory.

​

Configurer l’authentification multifacteur

Si vous devez utiliser le flux de mot de passe du propriétaire de la ressource, mais que vous avez besoin d’une authentification plus forte, vous pouvez ajouter l’authentification multifacteur (MFA). Pour savoir comment procéder, consultez S’authentifier à l’aide du flux de mot de passe du propriétaire de la ressource avec MFA.

​

Configurer la protection contre les attaques

Lorsque vous utilisez le flux de mot de passe du propriétaire de la ressource avec la protection contre la force brute, certaines fonctionnalités de la protection contre les attaques peuvent ne pas fonctionner. Toutefois, vous pouvez éviter certains problèmes courants. Pour en savoir plus, consultez Éviter les problèmes courants avec le flux de mot de passe du propriétaire de la ressource et la protection contre les attaques.

​

En savoir plus

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