Skip to main content
Dans certains cas (décrits ci-dessous), Auth0 შეიძლება devoir rediriger l’utilisateur vers le point de terminaison Login Initiation de l’application, en utilisant le third-party initiated login OIDC. 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 Application Settings ou Tenant Advanced Settings, ou avec l’.
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 contenant 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 Multiple Custom Domains ou Organizations, vous pouvez configurer 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 à l’exécution.

​
Espaces réservés pris en charge

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, lisez Espaces réservés d’URL de domaine personnalisé.
Les espaces réservés de métadonnées sont pris en charge uniquement pour initiate_login_uri au niveau de l’application, et non pour default_redirection_uri au niveau du tenant.

​
Comportement de secours

Auth0 utilise le default_redirection_uri au niveau du tenant comme solution de secours lorsqu’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 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 tenant comme solution de secours fiable.

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

​
Les utilisateurs ajoutent la page de connexion à leurs signets

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 à : 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 Organizations et que l’utilisateur final ajoute l’invite de connexion de l’organization à ses signets, 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 signets 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 redirigera l’utilisateur vers l’URL du client par défaut si elle est configurée, ou vers l’URL au niveau du tenant dans le cas contraire. Si aucune URL de connexion par défaut n’est définie, Auth0 affichera 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é et l’URI par défaut de l’application ou du tenant 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 tenants qui utilisent Universal Login, le point de terminaison /post-password-change permet de rediriger les 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 vers l’application après avoir terminé la réinitialisation du mot de passe.

​
Processus 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 arriveront sur une page indiquant que leur courriel a été vérifié, avec un bouton pour revenir à l’application. En cliquant sur ce bouton, ils seront redirigés vers la page de connexion et, s’ils ont déjà une session valide, ils seront 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 gabarit Verification Email.

​
Inviter des membres d’une organisation

Lorsque des utilisateurs sont invités à se joindre à une Organisation, ils reçoivent un lien d’invitation par courriel. S’ils cliquent sur ce lien, ils sont redirigés 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 qu’un URI de connexion de l’application est défini sur https://myapp.com/login, le lien envoyé dans le courriel d’invitation que recevra l’utilisateur final sera : https://myapp.com/login?invitation={invitation_ticket_id}&organization={organization_id}&organization_name={organization_name}. La route de votre application doit donc accepter les paramètres invitation et organization dans la chaîne de requête. Pour lancer la transaction d’acceptation de l’invitation, elle doit transmettre ces deux paramètres, ainsi que l’utilisateur final, à votre point de terminaison Auth0 /authorize.

​
Cookies désactivés

Si un utilisateur accède à https://{yourDomain}/authorize alors que les cookies sont désactivés dans son navigateur, Auth0 le redirige 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 tenant. 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 cookies ; s’ils sont désactivés, avertissez l’utilisateur qu’il doit les activer s’il souhaite continuer.

​
En savoir plus