Passer au contenu principal
Dans certains cas (décrits ci-dessous), Auth0 peut devoir rediriger vers le point de terminaison Login Initiation de l’application, au moyen d’une connexion OIDC initiée par un tiers. Pour en savoir plus, consultez Initiating Login from a Third Party sur le site de l’OpenID Foundation. Vous pouvez configurer ces URI dans le Dashboard, sous Paramètres de l’application ou Paramètres avancés du locataire, ou au moyen de la .
Le login_url doit pointer vers une route de l’application qui redirige ultimement vers le point de terminaison /authorize d’Auth0, par exemple https://mycompany.org/login. Notez qu’il doit utiliser https et qu’il ne peut pas pointer vers localhost. login_url peut inclure des paramètres de requête et un fragment d’URI. Conformément à la spécification OIDC Third Party Initiated Login, le paramètre iss, qui contient l’identifiant de l’émetteur, sera ajouté à login_url en tant que paramètre de chaîne de requête avant la redirection.

​
URI de connexion dynamiques avec des espaces réservés de métadonnées

Si vous utilisez Domaines personnalisés multiples ou Organisations, vous pouvez configurer la valeur initiate_login_uri au niveau de l’application pour y inclure des espaces réservés de métadonnées. Ces espaces réservés sont remplacés dynamiquement au moment de l’exécution.

​
Espaces réservés pris en charge

Espace réservéSourceExemple
{custom_domain.metadata.KEY}Métadonnées du domaine personnalisé utilisé dans la requêtehttps://{custom_domain.metadata.public_app_host}/login
{organization.metadata.KEY}Métadonnées de l’Organisation associée à la requêtehttps://{organization.metadata.public_login_host}/login
Les clés de métadonnées doivent commencer par public_ (par exemple, public_app_host). Les deux types d’espaces réservés peuvent être combinés dans la même URI si la requête comprend à la fois un domaine personnalisé et un contexte d’Organisation. Pour consulter la liste complète des règles de validation et des restrictions, consultez Espaces réservés d’URL de domaine personnalisé.
Les espaces réservés de métadonnées sont pris en charge uniquement dans le initiate_login_uri au niveau de l’application, et non dans le default_redirection_uri au niveau du locataire.

​
Comportement de repli

Auth0 utilise le default_redirection_uri du locataire comme solution de repli si un espace réservé ne peut pas être résolu. Par exemple, si l’Organisation est inconnue ou si la clé de métadonnées n’existe pas. Si le default_redirection_uri n’est pas non plus configuré, Auth0 affiche une page d’erreur. Nous recommandons de configurer un default_redirection_uri au niveau du locataire comme solution de repli fiable.

​
Scénarios de redirection pour la route de connexion par défaut

​
Les utilisateurs ajoutent la page de connexion à leurs favoris

Lorsqu’une application lance le processus de connexion, elle accède à https://{yourDomain}/authorize avec un ensemble de paramètres requis. Auth0 redirige ensuite les utilisateurs finaux vers une page https://{yourDomain}/login, avec une URL semblable à celle-ci : https://{yourDomain}/login?state=g6Fo2SBjNTRyanlVa3ZqeHN4d1htTnh&... Le paramètre state pointe vers un enregistrement dans une base de données interne où nous suivons l’état de la transaction d’autorisation. Une fois la transaction terminée, ou après un certain délai, l’enregistrement est supprimé de la base de données interne. Si vous utilisez les Organisations et que l’utilisateur final ajoute l’invite de connexion de l’organisation à ses favoris, Auth0 inclut aussi le paramètre organization lorsqu’il redirige l’utilisateur vers la route de connexion par défaut. Il arrive que des utilisateurs ajoutent la page de connexion à leurs favoris et que, lorsqu’ils accèdent à l’URL /login enregistrée, l’enregistrement de transaction n’existe plus et qu’Auth0 ne puisse pas poursuivre le flux de connexion. Dans ce cas, Auth0 redirige vers l’URL par défaut de l’application si elle est configurée, ou vers l’URL du locataire dans le cas contraire. Si aucune URL de connexion par défaut n’est définie, Auth0 affiche une page d’erreur.

​
Flux complet de réinitialisation du mot de passe

Une fois le flux de réinitialisation du mot de passe terminé, si l’URI par défaut de l’application ou du locataire est configuré, les utilisateurs verront un bouton leur permettant de revenir à la page de connexion. Ce comportement se produit uniquement lorsque vous activez l’expérience . Avec Classic Login, vous devez configurer l’URL de redirection dans le modèle Change Password. Pour en savoir plus, consultez Personnaliser les modèles de courriel. Pour les locataires qui utilisent Universal Login, le point de terminaison /post-password-change prend en charge la redirection des utilisateurs vers une application précise. Lorsque client_id est spécifié et que l’URI de connexion de l’application est définie, les utilisateurs verront un bouton qui les ramènera à l’application après la réinitialisation du mot de passe.

​
Flux complet de vérification du courriel

Dans le cadre du processus d’inscription, les utilisateurs qui choisissent le courriel comme identifiant reçoivent un courriel pour vérifier leur adresse courriel. S’ils cliquent sur le lien, ils arrivent sur une page indiquant que leur courriel a été vérifié, avec un bouton pour retourner à l’application. En cliquant sur ce bouton, les utilisateurs sont redirigés vers la page de connexion et, s’ils ont déjà une session valide, ils sont ensuite redirigés vers l’application. Ce comportement se produit uniquement lorsque l’expérience Universal Login est activée. Avec Classic Login, vous devez configurer l’URL de redirection dans le modèle Verification Email.

​
Inviter des membres d’une organisation

Lorsqu’un utilisateur est invité à rejoindre une Organisation, il reçoit un lien d’invitation par courriel. S’il clique sur le lien, il est redirigé vers la route de connexion par défaut configurée, à laquelle sont ajoutés des paramètres propres à l’invitation. Par exemple, si vous avez une application pour laquelle les organisations sont activées et dont l’URI de connexion de l’application est définie sur https://myapp.com/login, le lien envoyé dans le courriel d’invitation que reçoit l’utilisateur final sera le suivant : https://myapp.com/login?invitation={invitation_ticket_id}&organization={organization_id}&organization_name={organization_name}. Ainsi, la route de votre application doit accepter les paramètres invitation et organization dans la chaîne de requête. Pour démarrer la transaction d’acceptation de l’invitation, elle doit transmettre ces deux paramètres, avec l’utilisateur final, à votre point de terminaison Auth0 /authorize.

​
Témoins désactivés

Si un utilisateur accède à https://{yourDomain}/authorize alors que les témoins sont désactivés dans son navigateur, Auth0 redirige l’utilisateur vers l’URI de connexion de l’application. Si l’URI de connexion de l’application n’est pas définie, la redirection est plutôt envoyée vers l’URI de connexion du locataire. Renvoyer l’utilisateur à la page de connexion peut entraîner une boucle de redirection. Pour éviter ce problème, utilisez une page de destination pour vérifier la disponibilité des témoins; s’ils sont désactivés, avertissez l’utilisateur qu’il doit les activer s’il souhaite continuer.

​
En savoir plus