Faire une requête à l’API d’un fournisseur d’identité

Faites une requête à l’API d’un fournisseur d’identité social ou d’entreprise à partir de votre application Auth0 à l’aide du jeton d’accès du fournisseur qu’Auth0 a stocké après la connexion de l’utilisateur.

Si Token Vault est activé pour votre connexion, les jetons d’accès et d’actualisation ne seront plus stockés dans le tableau identities de l’utilisateur. Ils seront plutôt stockés dans un ensemble de jetons sécurisé dans Token Vault. Pour activer Token Vault, consultez Configurer Token Vault.

Une fois que vous avez authentifié avec succès un utilisateur auprès d’un fournisseur d’identité (IdP) externe, comme Facebook ou GitHub, l’IdP inclut souvent un jeton d’accès dans le profil utilisateur qu’il renvoie à Auth0.

Vous pouvez récupérer et utiliser ce jeton pour effectuer une requête à l’API de l’IdP.

Cet article suppose que vous avez déjà configuré la connexion avec l’IdP de votre choix. Sinon, consultez Fournisseurs d’identité pris en charge par Auth0, sélectionnez l’IdP souhaité et suivez les étapes de configuration.

Le processus à suivre diffère selon que votre code s’exécute dans le backend ou dans le frontend :

• Si votre code s’exécute dans le backend, nous pouvons supposer que votre serveur est digne de confiance et peut stocker des secrets en toute sécurité (comme vous le verrez, nous utilisons un secret dans le scénario backend). Si c’est le cas, passez à la section backend de cet article.
• Si votre code s’exécute dans le frontend (par exemple, il s’agit d’une SPA, d’une application de bureau native ou d’une application mobile), votre application ne peut pas stocker des informations d’authentification de façon sécurisée et doit suivre une autre approche. Dans ce cas, passez à la section frontend de cet article.

​

Depuis le backend

Une fois que vous avez authentifié un utilisateur, l’IdP inclut souvent un jeton d’accès dans le profil utilisateur qu’il renvoie à Auth0.

Pour des raisons de sécurité et de conformité, Auth0 n’envoie pas ce jeton à votre application dans le profil utilisateur. Pour l’obtenir, vous devez accéder à l’API Auth0 Management API et récupérer le profil complet de l’utilisateur :

1. Obtenez un jeton d’accès qui vous permet d’effectuer une requête à l’Auth0 Management API.
2. Effectuez une requête à l’point de terminaison Get Users by ID de l’Auth0 Management API à l’aide du jeton d’accès obtenu à l’étape 1. Cet point de terminaison renvoie le profil complet de l’utilisateur, qui contient le jeton d’accès de l’IdP.
3. Extrayez le jeton d’accès de l’IdP de la réponse et utilisez-le pour effectuer une requête à l’API de l’IdP.

​

Étape 1 : Obtenir un jeton

Vous aurez besoin d’un jeton d’accès pour effectuer une requête à la Management API.

​

Créer une application de test pour la Management API

Si c’est la première fois que vous demandez un Management APIv2 Token, vous devrez créer et configurer une application qui pourra être utilisée pour appeler la Management API :

1. Accédez à Auth0 Dashboard > Applications > APIs, puis sélectionnez l’Auth0 Management API.
2. Sélectionnez la vue API Explorer, puis cliquez sur Create & Authorize a Test Application.

Cela créera une nouvelle application et lui accordera tous les scopes de la Management API, ce qui signifie que les jetons générés pour cette application pourront accéder à tous les points de terminaison de la Management API.

Vous ne voyez pas le bouton ?

Si vous ne voyez pas ce bouton, cela signifie que vous avez déjà au moins une application autorisée pour la Management API. Dans ce cas, vous pouvez soit mettre à jour les scopes de l’application existante et l’utiliser, soit en créer une nouvelle en suivant ces étapes :

1. Accédez à Auth0 Dashboard > Applications > Applications, puis sélectionnez Create Application.
2. Sélectionnez Machine to Machine Applications, puis Create.
3. Dans la liste déroulante Select an API, sélectionnez Auth0 Management API.
4. Activez les scopes requis, puis sélectionnez Authorize.
5. Sélectionnez la vue APIs, puis activez la bascule pour Auth0 Management API.

Pour des raisons de sécurité, nous vous recommandons d’attribuer uniquement les scopes requis à l’application que vous utiliserez. Dans ce cas précis, les scopes dont vous avez besoin sont : read:users, read:user_idp_tokens. Les scopes requis sont indiqués pour chaque point de terminaison dans le Management API Explorer.

Pour accorder ou supprimer des scopes de l’Auth0 Management API enregistrée, sélectionnez la vue Machine to Machine Applications :

​

Obtenir le jeton de la Management API

Vous avez maintenant terminé la configuration et êtes prêt à obtenir votre jeton de la Management API :

1. Dans la Auth0 Management API enregistrée, sélectionnez la vue Test.
2. Choisissez votre application dans la liste déroulante Application pour préremplir les extraits de code prêts à l’emploi avec des variables personnalisées.
3. Choisissez la langue de votre choix pour l’extrait de code, puis copiez-le et exécutez-le.
4. Extrayez la propriété access_token de la réponse. C’est ce que vous utiliserez pour accéder à la Management API.

Que font les extraits de code ?

Les extraits de code effectuent une requête POST vers l’point de terminaison /oauth/token de l’Auth0 Authentication API, en utilisant le grant Client Credentials d’OAuth 2.0. C’est le grant que les processus machine-to-machine utilisent pour accéder à une API. Pour en savoir plus sur ce flux, consultez Client Credentials Flow.

​

Expiration du jeton

Par défaut, le jeton que vous avez reçu expire après 24 heures (86 400 secondes). Pour modifier ce paramètre :

1. Accédez à Auth0 Dashboard > Applications > APIs, puis sélectionnez l’Auth0 Management API.
2. Sélectionnez la vue Settings, repérez le champ Token Expiration (Seconds), saisissez une nouvelle valeur, puis cliquez sur Save. La valeur maximale que vous pouvez définir est de 2 592 000 secondes (30 jours), bien que nous vous recommandions de conserver la valeur par défaut.

Le prochain jeton que vous générerez utilisera le nouveau délai d’expiration.

Ces jetons ne peuvent pas être révoqués. Pour réduire les risques, nous vous recommandons d’émettre des jetons de courte durée et de n’accorder que les scopes nécessaires à chaque application. Dans un environnement de production, vous pouvez configurer une CLI simple qui ira récupérer un nouveau jeton lorsque l’ancien expirera.

​

Étape 2 : Obtenir le profil utilisateur complet

Pour obtenir le profil d’un utilisateur, effectuez une requête au point de terminaison Get a User de la Management API à l’aide du jeton d’accès que vous avez extrait dans la section précédente :

Remplacez les valeurs suivantes :

• {userId} : ID de l’utilisateur pour lequel vous voulez effectuer une requête à l’API de l’IdP.
• {yourAccessToken} : jeton d’accès que vous avez extrait dans la section précédente.

Où trouver l’ID utilisateur ?

• À des fins de test, vous pouvez trouver un ID utilisateur dans Auth0 Dashboard > User Management > Users. Repérez un utilisateur et copiez la valeur du champ user_id.

• Pour votre mise en œuvre, vous pouvez soit extraire l’ID utilisateur de la claim sub dans le ID Token, soit effectuer une requête au point de terminaison /userinfo de la Authentication API et l’extraire de la propriété de réponse user_id.

​

Étape 3 : Extraire le jeton d’accès de l’IdP

Vous trouverez le jeton d’accès utilisé pour envoyer une requête à l’API de l’IdP dans le tableau identities de l’utilisateur : user.identities[0].access_token.

Pour certains fournisseurs d’identité, Auth0 stocke également un jeton d’actualisation, que vous pouvez utiliser pour obtenir un nouveau jeton d’accès de l’IdP. Cela fonctionne pour : BitBucket, Google (OAuth 2.0), OAuth 2.0, SharePoint et Azure AD. Pour en savoir plus, consultez Jetons d’accès du fournisseur d’identité.

Dans la plupart des cas, l’utilisateur n’aura qu’une seule identité, mais s’il s’est connecté plusieurs fois au moyen de différentes connexions et que vous avez utilisé la liaison de comptes, il peut y en avoir plusieurs.

Dans cet exemple de réponse, nous voyons que notre utilisateur n’a qu’une seule identité : google-oauth2.

{
  "email": "[e-mail]",
  "email_verified": true,
  "name": "John Doe",
  "given_name": "John",
  "family_name": "Doe",
  "picture": "https://myavatar/photo.jpg",
  "gender": "male",
  "locale": "en",
  "updated_at": "2017-03-15T07:14:32.451Z",
  "user_id": "google-oauth2|111199914890750704174",
  "nickname": "john.doe",
  "identities": [
    {
      "provider": "google-oauth2",
      "access_token": "ya29.GlsPBCS6ahokDlgCYnVLnDKNE71HBXPEzNhAPoKJLAGKDSe1De3_xclahNcdZXoU-26hCpa8h6240TV86dtaEQ4ZWoeeZduHDq_yeu9QyQqUr--S9B2CR9YJrLTD",
      "expires_in": 3599,
      "user_id": "111199914890750704174",
      "connection": "google-oauth2",
      "isSocial": true
    }
  ],
  "created_at": "2017-03-15T07:13:41.134Z",
  "last_ip": "127.0.0.1",
  "last_login": "2017-03-15T07:14:32.451Z",
  "logins_count": 99
}

Vous êtes maintenant prêt à appeler l’API de l’IdP. Veuillez consulter la documentation de l’IdP pour savoir comment procéder.

N’exposez pas les jetons de l’IdP dans votre application côté client! Si votre application est publique, consultez la section frontend de cet article.

Pour en savoir plus sur la façon de demander des scopes/autorisations spécifiques pour un jeton d’accès du fournisseur d’identité, consultez Ajouter des scopes/autorisations pour appeler les API du fournisseur d’identité.

​

Côté frontend

Si vous travaillez avec une application publique (SPA, application native de bureau ou application mobile), vous êtes au bon endroit.

Lorsque vous travaillez avec une application frontend, le processus pour appeler les API de l’IdP diffère de celui du backend, car les applications frontend sont des applications publiques qui ne peuvent pas stocker des informations d’authentification de façon sécuritaire. Comme le code d’une SPA peut être consulté et modifié, et que les applications natives ou mobiles peuvent être décompilées et inspectées, on ne peut pas leur faire confiance pour stocker des renseignements sensibles, comme des clés secrètes ou des mots de passe.

Plus précisément, elles ne peuvent pas stocker de façon sécuritaire le Secret du client de la Machine to Machine Application, que vous utilisez pour appeler /oauth/token à la première étape du processus backend.

Vous devez plutôt créer un proxy pour votre backend et l’exposer à votre application sous forme d’API.

​

Créer un proxy

D’abord, vous allez créer un processus dans votre backend qui mettra en œuvre les étapes décrites dans la section backend de cet article, puis l’exposer à votre application sous forme d’API.

Vous appellerez l’API de l’IdP depuis ce même processus backend, afin que le jeton d’accès ne soit jamais exposé à votre application publique.

Ensuite, vous appellerez votre API proxy à partir de votre application publique en utilisant le flux du code d’autorisation avec clé de preuve pour l’échange de code (PKCE).

Montrez-moi comment faire

Si c’est la première fois que vous mettez cela en œuvre, notre scénario d’architecture Applications monopages (SPA) avec API pourrait vous être utile. Il couvre un scénario différent, mais explique comment configurer Auth0, comment appeler une API depuis une SPA et comment mettre en œuvre les validations d’API. Il comprend un exemple qui utilise Angular 2 et Node.js.

Nous proposons aussi une variante Applications mobiles avec API (l’exemple utilise Android et Node.js).