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

Apprenez à appeler votre propre API à partir d’applications hautement fiables à l’aide du Flux de mot de passe du propriétaire de ressource.

Ce tutoriel vous aidera à appeler votre propre API au moyen du flux de mot de passe du propriétaire de ressource. Si vous souhaitez apprendre comment le flux fonctionne et pourquoi vous devriez l’utiliser, consultez Flux de mot de passe du propriétaire de ressource.

Étant donné que le flux ROP (Resource Owner Password) implique 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 de mettre en œuvre facilement le Flux de mot de passe du propriétaire de ressource (parfois appelé « Autorisation de mot de passe du propriétaire de ressource ») en utilisant l’Authentication API (API d’authentification). Continuez à lire pour savoir comment appeler votre API directement.

​

Prérequis

Avant de commencer ce tutoriel :

• Enregistrez votre application avec Auth0.

  • Sélectionnez le type d’application parmi les Applications web classiques.
  • Ajoutez une URL de rappel autorisée de {https://yourApp/callback}. Ce champ ne peut pas être vide, sinon un message d’erreur s’affichera.
  • Assurez-vous que les Grant Types (Types d’autorisation) de votre application comprennent le Password (Mot de passe). Pour en savoir plus, lisez Mettre à jour les types d’autorisation
  • Si vous souhaitez que votre application puisse utiliser des jetons d’actualisation, assurez-vous que les Grant Types (Types d’autorisation) de l’application comprennent le Refresh Token (Jetons d’actualisation). Pour en savoir plus, lisez l’article Mettre à jour les types d’autorisation. Pour en savoir plus sur les jetons d’actualisation, lisez l’article Jetons d’actualisation.

• Enregistrez votre application avec Auth0

  • Si vous souhaitez que votre API reçoive des jetons d’actualisation afin d’obtenir de nouveaux jetons lorsque les précédents expirent, activez Autoriser l’accès hors ligne.

• Configurer une connexion

  • Assurez-vous que votre connexion est capable d’authentifier des utilisateurs grâce à leur nom d’utilisateur et leur mot de passe (par exemple, connexions aux bases de données, ou les connexions d’entreprise AD/LDAP, ADFS, ou Azure Active Directory).

• Mettez à jour ou désactivez toutes les rules(règles), pour qu’elles n’impactent que des connexions spécifiques. Si le message access_denied s’affiche lorsque vous testez l’autorisation de mot de passe du propriétaire de ressource, cela peut être dû à une règle de contrôle d’accès.

​

Étapes

1. Configurez le locataire :Définissez la connexion par défaut du locataire.
2. Request tokens (Demande de jetons) : échangez votre code d’autorisation contre des jetons.
3. Appelez l’API : Utilisez le jeton d’accès récupéré pour appeler votre API.
4. Jetons d’actualisation : utilisez un jeton d’actualisation pour demander de nouveaux jetons lorsque les anciens expirent.

Facultatif : Découvrez des cas d’utilisation

Facultatif : Configurer la prise en charge des partitions

Facultatif : Configurer MFA

Facultatif : Configurer les paramètres de protection contre les attaques

​

Configurez le locataire

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

1. Accédez au Auth0 Dashboard > Paramètres du locataire, et faites défiler vers le bas pour trouver le paramètre Répertoire par défaut.
2. Sélectionnez le nom de la connexion que vous souhaitez utiliser. Assurez-vous qu’elle est capable d’authentifier les utilisateurs par leur nom d’utilisateur et leur mot de passe.

​

Demander des jetons

Pour appeler votre API, vous devez d’abord obtenir les identifiants de l’utilisateur, généralement via un formulaire interactif. Une fois que votre application dispose des identifiants, vous devez les échanger contre des jetons. Pour ce faire, vous devez POST (PUBLIER) vers l’URL du jeton.

​

Exemple d’un POST à une URL de jeton

cURL

curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=password \
  --data 'username={username}' \
  --data 'password={password}' \
  --data 'audience={yourApiIdentifier}' \
  --data scope=read:sample \
  --data 'client_id={yourClientId}' \
  --data 'client_secret={yourClientSecret}'

Paramètres

Nom du paramètre	Description
grant_type	Définir 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 vos paramètres de l’application.
client_assertion	Un JWT contenant une assertion signée avec les identifiants de votre application. Requis lorsque la méthode d’authentification de l’application est une clé privée JWT.
client_assertion_type	La valeur est urn:ietf:params:oauth:client-assertion-type:jwt-bearer. Requis lorsque la méthode d’authentification de l’application est une clé privée JWT.
client_secret	Secret du client de votre application. Requis lorsque le secret du client est la méthode d’authentification de l’application. Paramètres de l’application est Post ou Basic. Si votre application n’est pas très fiable (p. ex., une SPA), ne définissez pas ce paramètre.
audience	L’audience du jeton, qui est votre API. Vous pouvez le trouver dans le champ Identifiant de votre onglet des paramètres de l’API.
scope	Indique les permissions pour lesquelles vous souhaitez demander une autorisation, qui déterminent les demandes (ou les attributs de l’utilisateur) à renvoyer. Elles doivent être séparées par un espace. Vous pouvez demander n’importe laquelle des permissions standard d’OpenID Connect (OIDC) about users, such as profile or email, demandes personnalisées conforme au format espace de nom, ou toutes les permissions prises en charge par l’API cible (p. ex., read:contacts). Incluez offline_access pour obtenir un Jeton d’actualisation (assurez-vous que le champ Autoriser l’accès hors ligne est activé dans les paramètres de l’application).

​

Réponse

Si tout se passe bien, vous recevrez une réponse HTTP 200 avec une charge utile 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 en savoir plus, lisez Valider les jetons d’ID et Valider les jetons d’accès.

Les jetons d’actualisation doivent être stockés en toute sécurité car ils permettent aux utilisateurs de rester authentifiés pratiquement indéfiniment.

Permissions standard et Flux de mot de passe du propriétaire de ressource

Étant donné que fournir un mot de passe vous donne un accès total, tout échange basé sur un mot de passe donne accès à toutes les permissions. Par exemple, si vous n’incluez aucune Permissions des API dans la demande, toutes les permissions des API seront incluses dans le jeton d’accès. De même, si vous incluez uniquement la permission openid dans votre demande, toutes les permissions OpenID Connectopenid standards seront renvoyées. Dans ces cas, le paramètre scope sera inclus dans la réponse et donnera la liste des permissions émises.

Obtenir les informations de l’utilisateur sans jeton d’ID

Si vous avez besoin des informations de l’utilisateur, incluez la permission openid dans votre demande. Si l’API utilise RS256 comme algorithme de signature , le jeton d’accès incluera /userinfo comme audience valide, signifiant que vous pouvez l’utiliser pour invoquer le point de terminaison /userinfo et récupérer les demandes de l’utilisateur.

​

Appeler l’API

Pour appeler votre API, l’application doit transmettre le jeton d’accès récupéré en tant que jeton du porteur dans l’en-tête d’autorisation de votre requête HTTP.

cURL

curl --request GET \
  --url https://myapi.com/api \
  --header 'authorization: Bearer {accessToken}' \
  --header 'content-type: application/json'

​

Jetons d’actualisation

Vous avez déjà reçu un jeton d’actualisation si vous avez suivi ce tutoriel et complété ce qui suit :

• configuré votre API pour autoriser l’accès hors ligne
• inclus la permission offline_access lorsque vous avez lancé la demande d’authentification via le point de terminaison d’autorisation.

Vous pouvez utiliser le jeton d’actualisation pour obtenir le nouveau jeton d’accès. Généralement, un utilisateur aura besoin d’un nouveau jeton d’accès uniquement 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 impose des limites anti-attaques qui réduiront la quantité de requêtes au point de terminaison pouvant être exécutées en utilisant le même jeton depuis la même adresse IP.

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

​

Exemple d’un POST à une URL de jeton

cURL

curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=refresh_token \
  --data 'client_id={yourClientId}' \
  --data 'refresh_token={yourRefreshToken}'

Paramètres

Nom du paramètre	Description
grant_type	Définir ce paramètre à refresh_token.
client_id	L’ID client de votre application. Vous pouvez trouver cette valeur dans vos Paramètres d’application.
refresh_token	Le jeton d’actualisation à utiliser.
scope	(facultatif) Une liste délimitée par des espaces des permissions demandées. Si elle n’est pas envoyée, les permissions originales seront utilisées; sinon vous pouvez demander un ensemble réduit de permissions. Veuillez noter que cela doit être codé URL.

​

Réponse

Si tout se passe bien, vous recevrez une réponse HTTP 200 avec une charge utile contenant un nouveau access_token , sa durée de vie 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 en savoir plus, lisez Valider les jetons d’ID et Valider les jetons d’accès.

​

Exemples de cas d’utilisation

​

Personnalisation des jetons

Vous pouvez utiliser des règles pour modifier les permissions des jetons d’accès et/ou ajouter des demandes pour les jetons d’accès et d’ID. (Pour en savoir plus sur les règles, lisez l’article Règles d’Auth0.) Pour ce faire, ajoutez la règle suivante, qui s’exécutera après l’authentification de l’utilisateur :

exports.onExecutePostLogin = async (event, api) => {
  // Add custom claims to Access Token and ID Token
  api.accessToken.setCustomClaim('https://foo/bar', 'value');
  api.idToken.setCustomClaim('https://fiz/baz', 'some other value');

  // Modify the scope of the Access Token
  api.accessToken.addScope('foo');
  api.accessToken.addScope('bar');
};

Les permissions seront disponibles dans le jeton une fois toutes les règles exécutées.

Auth0 renvoie les informations de profil contenues dans un format de demande structuré tel que défini par la spécification OpenID Connect (OIDC). Cela signifie que les demandes personnalisées ajoutées aux jetons d’ID ou aux jetons d’accès doivent respecter des directives et des restrictions pour éviter d’éventuels conflits.

​

Configurer la prise en charge des partitions

Auth0 fournit une autorisation d’extension semblable à l’autorisation de mot de passe du propriétaire de ressource, qui vous permet de conserver des répertoires d’utilisateurs distincts (qui correspondent à des connexions distinctes) et de spécifier celui qui doit être utilisé 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 appelé realm (partition), et lui attribuer le nom de la partition auquel l’utilisateur appartient. Par exemple, si vous avez configuré une connexion à la base de données pour des employés internes appelée employees (employés), et que votre utilisateur en fait partie, définissez alors realm (partition) sur employees (employés).

Connexions en tant que partitions

Toute connexion qui prend en charge l’authentification active peut être configurée comme une partition, notamment les connexions à des bases de données, les connexions sans mot de passe et les connexions d’entreprise AD/LDAP, ADFS et Azure Active Directory.

​

Configurer MFA

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

​

Configurer les paramètres de protection contre les attaques

Lorsque vous utilisez le Flux de mot de passe du propriétaire de ressource avec une protection contre les attaques de force brute, certaines fonctionnalités de protection contre les attaques peuvent échouer. Certains problèmes courants peuvent toutefois être évités. Pour en savoir plus, lisez l’article Éviter les problèmes courants en utilisant Flux de mot de passe du propriétaire de ressource et Protection contre les attaques.

​

En savoir plus

• Cadre d’applications Authorization OAuth 2.0
• Protocole OpenID Connect
• Jetons