Ajouter la connexion avec le flux implicite avec Form Post

Découvrez comment ajouter la connexion à votre application monopage (SPA) à l’aide du flux implicite avec Form Post.

Vous pouvez ajouter la connexion à votre application monopage (SPA) à l’aide du flux implicite avec Form Post. Pour savoir comment fonctionne ce flux et pourquoi vous devriez l’utiliser, consultez flux implicite avec Form Post.

Utilisez le flux implicite avec Form Post pour les cas d’utilisation axés uniquement sur la connexion; si vous devez demander des jetons d’accès pendant la connexion de l’utilisateur afin de pouvoir appeler votre API, utilisez le flux du code d’autorisation avec PKCE. Pour en savoir plus, consultez Authorization Code Flow with Proof Key for Code Exchange (PKCE).

Pour mettre en œuvre le flux implicite avec Form Post, vous pouvez utiliser les ressources suivantes :

• Express OpenID Connect SDK : La façon la plus simple de mettre en œuvre ce flux; il effectuera la majeure partie du travail pour vous. Si vous utilisez notre SDK Javascript, assurez-vous de mettre en place des mesures d’atténuation adaptées à votre architecture. Pour en savoir plus, consultez Auth0.js Reference.
• Authentication API : Si vous préférez créer votre propre solution, poursuivez votre lecture pour apprendre à appeler directement notre API.

À la suite d’une connexion réussie, votre application aura accès à l’jeton d’identité de l’utilisateur. Le jeton d’identité contiendra les renseignements de base du profil utilisateur.

​

Prérequis

Enregistrez votre application dans Auth0. Pour en savoir plus, consultez Enregistrer des applications monopages.

• Sélectionnez Application monopage comme Type d’application.
• Ajoutez {https://yourApp/callback} comme URL de rappel autorisée.
• Assurez-vous que les types d’octroi de votre application incluent Implicit. Pour en savoir plus, consultez Mettre à jour les types d’octroi.

​

Autoriser l’utilisateur

Demandez l’autorisation de l’utilisateur et redirigez-le vers votre application. Pour lancer le processus, vous devrez obtenir l’autorisation de l’utilisateur. Cette étape peut inclure un ou plusieurs des processus suivants :

• Authentifier l’utilisateur ;
• Rediriger l’utilisateur vers un fournisseur d’identité pour prendre en charge l’authentification ;
• Vérifier la présence de sessions d’authentification unique (SSO) actives ;
• Obtenir le consentement de l’utilisateur pour le niveau de permission demandé, sauf si ce consentement a déjà été donné.

Pour autoriser l’utilisateur, votre application doit l’envoyer vers l’URL d’autorisation.

​

Exemple d’URL d’autorisation

​

Paramètres

Nom du paramètre	Description
response_type	Indique le type d’identifiant qu’Auth0 renverra (code ou token). Pour le flux implicite, la valeur peut être id_token, token ou id_token token. Plus précisément, id_token renvoie un jeton d’identité et token renvoie un jeton d’accès.
response_mode	Précise la façon dont les paramètres de réponse doivent être renvoyés. Pour des raisons de sécurité, la valeur doit être form_post. Dans ce mode, les paramètres de réponse sont encodés comme des valeurs de formulaire HTML, transmises au moyen de la méthode HTTP POST et encodées dans le corps au format application/x-www-form-urlencoded.
client_id	Le Client ID de votre application. Vous pouvez trouver cette valeur dans les paramètres de votre application.
redirect_uri	L’URL vers laquelle Auth0 redirigera le navigateur une fois que l’utilisateur aura accordé l’autorisation. Vous devez indiquer cette URL comme URL de rappel valide dans les Application Settings de votre application. Avertissement : Conformément à la spécification OAuth 2.0, Auth0 supprime tout ce qui suit le dièse et ne tient pas compte des fragments.
scope	Précise 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) standard concernant les utilisateurs, comme profile et email, des claims personnalisées conformes à un format avec espace de noms, ou tout scope pris en charge par l’API cible (par exemple, read:contacts).
state	(recommandé) Une chaîne alphanumérique arbitraire opaque que votre application ajoute à la requête initiale et qu’Auth0 inclut lors de la redirection vers votre application. Pour savoir comment utiliser cette valeur afin de prévenir les attaques de falsification de requête intersites (CSRF), consultez Atténuer les attaques CSRF avec les paramètres d’état.
nonce	(obligatoire pour response_type contenant id_token token, sinon recommandé) Une chaîne aléatoire cryptographiquement sûre que votre application ajoute à la requête initiale et qu’Auth0 inclut dans le jeton d’identité, utilisée pour prévenir les attaques par rejeu de jeton.
connection	(facultatif) Force l’utilisateur à se connecter avec une connexion précise. Par exemple, vous pouvez transmettre la valeur github pour envoyer l’utilisateur directement vers GitHub afin qu’il se connecte avec son compte GitHub. Lorsqu’elle n’est pas précisée, l’utilisateur voit l’écran Auth0 Lock avec toutes les connexions configurées. Vous pouvez consulter la liste de vos connexions configurées dans l’onglet Connections de votre application.
organization	(facultatif) ID de l’organisation à utiliser lors de l’authentification d’un utilisateur. S’il n’est pas fourni, et si votre application est configurée pour Display Organization Prompt, l’utilisateur pourra saisir le nom de l’organisation pendant l’authentification.
invitation	(facultatif) ID du ticket d’invitation de l’organisation. Lorsque vous invitez un membre dans une organisation, votre application doit gérer l’acceptation de l’invitation en transmettant les paires clé-valeur invitation et organization lorsque l’utilisateur accepte l’invitation.

À titre d’exemple, votre extrait HTML pour l’URL d’autorisation lors de l’ajout de la connexion à votre application pourrait ressembler à ceci :

​

Réponse

Si tout se passe bien, vous recevrez une réponse HTTP 302. Les données d’authentification demandées sont encodées dans le corps :

HTTP/1.1 302 Found
Content-Type: application/x-www-form-urlencoded
id_token=eyJ...acA&
state=xyzABC123

Notez que les valeurs renvoyées dépendent du response_type que vous avez demandé.

Type de réponse	Composants
id_token	jeton d’identité
token	jeton d’accès (avec les valeurs expires_in et token_type)
id_token token	jeton d’identité, jeton d’accès (avec les valeurs expires_in et token_type)

Auth0 renverra aussi toute valeur state que vous avez incluse dans votre requête vers l’URL d’autorisation.

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

Les jetons d’identité contiennent des renseignements sur l’utilisateur qui doivent être décodés et extraits.

​

Cas d’utilisation

​

Requête d’authentification de base

Cet exemple montre la requête la plus simple que vous puissiez faire lors de l’autorisation de l’utilisateur à l’étape 1. Il affiche l’écran de connexion Auth0 et permet à l’utilisateur d’ouvrir une session avec n’importe laquelle de vos connexions configurées :

Cela renverra un jeton d’identité, que vous pouvez extraire de votre URL de redirection.

​

Demander le nom de l’utilisateur et sa photo de profil

En plus du processus habituel d’authentification de l’utilisateur, cet exemple montre comment demander des renseignements supplémentaires sur l’utilisateur, comme son nom et sa photo de profil.

Pour demander le nom et la photo de profil de l’utilisateur, vous devez ajouter les scopes appropriés lors de l’autorisation de l’utilisateur :

Maintenant, votre jeton d’identité contiendra les claims name et picture demandés. Lorsque vous décoderez le jeton d’identité, il ressemblera à ceci :

{
  "name": "jerrie@...",
  "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png",
  "iss": "https://auth0pnp.auth0.com/",
  "sub": "auth0|581...",
  "aud": "xvt...",
  "exp": 1478113129,
  "iat": 1478077129
}

​

Demander à l’utilisateur de se connecter avec GitHub

En plus de l’authentification utilisateur habituelle, cet exemple montre comment rediriger les utilisateurs directement vers un fournisseur d’identité social, comme GitHub. Pour que cet exemple fonctionne, vous devez aller dans Auth0 Dashboard > Authentication > Social et configurer la connexion appropriée. Récupérez le nom de la connexion dans l’onglet Settings.

Pour envoyer les utilisateurs directement à l’écran de connexion GitHub, vous devez transmettre le paramètre connection et définir sa valeur sur le nom de la connexion (dans ce cas, github) au moment d’autoriser l’utilisateur :

Désormais, votre jeton d’identité contiendra une claim sub comprenant l’ID unique de l’utilisateur renvoyé par GitHub. Une fois décodé, le jeton d’identité ressemblera à ceci :

{
  "name": "Jerrie Pelser",
  "nickname": "jerriep",
  "picture": "https://avatars.githubusercontent.com/u/1006420?v=3",
  "iss": "https://auth0pnp.auth0.com/",
  "sub": "github|100...",
  "aud": "xvt...",
  "exp": 1478114742,
  "iat": 1478078742
}

​

En savoir plus

• Cadre d’autorisation OAuth 2.0
• Protocole OpenID Connect
• Jetons
• Atténuer les attaques par rejeu lors de l’utilisation du Flux implicite
• Enregistrer des applications Web monopages
• Mettre à jour les type d’octroi