Vérifier les problèmes de connexion et de déconnexion

Découvrez comment vérifier les étapes de connexion et de déconnexion pour résoudre les problèmes

Voici quelques points à vérifier pour vous aider à déterminer à quel moment les problèmes surviennent lors de la connexion et de la déconnexion.

Problèmes de connexion

L’utilisateur est-il invité à saisir ses identifiants ?

• Le fichier HAR montre-t-il un appel au serveur d’autorisation (point de terminaison /authorize)?

  Avant de partager un fichier HAR avec qui que ce soit (y compris Auth0), assurez-vous de supprimer ou d’obfusquer toutes les données sensibles, comme :

  • Renseignements confidentiels sur l’utilisateur
  • Renseignements personnels identifiables (PII)
  • Renseignements confidentiels sur l’application

  Pour en savoir plus, consultez les articles suivants sur communauté Auth0 :

  • Nettoyer les traces HTTP
  • Comment nettoyer automatiquement un fichier de trace HTTP
  • Comment caviarder manuellement les renseignements sensibles
  • Le fichier HAR est trop volumineux pour être téléversé dans le dossier d’assistance

• La connexion est-elle activée pour l’application ?

• Le service d’autorisation distant est-il disponible ?

• Si vous utilisez la page Universal Login d’Auth0, essayez de désactiver la personnalisation et vérifiez si l’authentification fonctionne. Si la connexion fonctionne sans vos personnalisations, examinez le code de personnalisation de votre page Universal Login.

Un message d’erreur s’affiche-t-il après la saisie des identifiants ?

• Pouvez-vous essayer de vous connecter d’une autre façon pour vous assurer que les identifiants sont corrects ?

• Si l’expiration du mot de passe est possible, vérifiez si le mot de passe a expiré.

• Vérifiez les outils de développement de votre navigateur ou la console de l’inspecteur Web pour repérer les erreurs dans le flux avant le retour à Auth0.

• Vérifiez le fichier HAR - montre-t-il un retour vers Auth0 (point de terminaison /login/callback) ?

  Avant de partager un fichier HAR avec qui que ce soit (y compris Auth0), assurez-vous de supprimer ou de masquer toutes les données sensibles, telles que :

  • des renseignements confidentiels sur l’utilisateur
  • des renseignements personnels identifiables (PII)
  • des renseignements confidentiels sur l’application

  Pour en savoir plus, consultez les articles suivants sur la communauté Auth0 :

  • Assainir les traces HTTP
  • Comment assainir automatiquement un fichier de trace HTTP
  • Comment caviarder manuellement des renseignements sensibles
  • Le fichier HAR est trop volumineux pour être téléversé dans le dossier d’assistance
  • Si ce n’est pas le cas, vérifiez que le fournisseur d’identité est configuré avec la bonne URL de rappel pour Auth0.

Une session de connexion est-elle établie pour l’utilisateur sur le serveur d’autorisation ?

• Pour le vérifier, ouvrez un deuxième onglet dans le même navigateur et accédez à la même URL. Êtes-vous invité à vous reconnecter ?

  • Si vous n’êtes pas invité à vous reconnecter, une session existe.

Une entrée de journal a-t-elle été créée dans les journaux Auth0?

• Si aucune entrée de journal n’a été créée, la transaction d’authentification n’a pas abouti ou n’est pas revenue à Auth0.
• Vérifiez la réponse du serveur d’autorisation pour voir s’il contient des messages d’erreur.
• Vérifiez les journaux du serveur d’autorisation (si possible) pour repérer des erreurs.

Une entrée est-elle créée dans l’écran utilisateur d’Auth0 avec tous les bons renseignements de profil ?

• Si ce n’est pas le cas, vérifiez la réponse du serveur d’autorisation dans le fichier HAR. Il se peut qu’elle ne renvoie aucune information sur l’utilisateur.

  Avant de partager un fichier HAR avec qui que ce soit (y compris Auth0), assurez-vous de supprimer ou d’obfusquer toutes les données sensibles, comme :

  • Renseignements confidentiels sur l’utilisateur
  • Renseignements personnels identifiables (PII)
  • Renseignements confidentiels sur l’application

  Pour en savoir plus, consultez les articles suivants dans la communauté Auth0 :

  • Sanitizing HTTP Traces
  • How to Sanitize an HTTP Trace File Automatically
  • How to Manually Redact Sensitive Information
  • HAR File is Too Large to Upload to the Support Case

• Si vous utilisez des Rules, vérifiez s’il y a des problèmes dans vos scripts Rules.

• Si vous utilisez une connexion de base de données personnalisée, vérifiez s’il y a des problèmes dans vos scripts d’action de base de données.

• Si vous utilisez LDAP, vérifiez s’il y a des problèmes dans le script de mappage de profil (profileMapper.js).

• Vérifiez la configuration de vos connexions sociales pour voir quelles informations de profil sont demandées.

Le fichier HAR montre-t-il un jeton ou une assertion renvoyé à l’application ?

• Recherchez dans le fichier HAR l’appel à votre Application Callback URL.

  Avant de partager un fichier HAR avec qui que ce soit (y compris Auth0), assurez-vous de supprimer ou d’obfusquer toutes les données sensibles, par exemple :

  • Des renseignements confidentiels sur l’utilisateur
  • Des renseignements personnels identifiables (PII)
  • Des renseignements confidentiels sur l’application

  Pour en savoir plus, consultez les articles suivants dans la communauté Auth0 :

  • Nettoyer les traces HTTP
  • Comment nettoyer automatiquement un fichier de trace HTTP
  • Comment masquer manuellement des renseignements sensibles
  • Le fichier HAR est trop volumineux pour être téléversé dans le dossier d’assistance

• Repérez le ID Token (id_token) et vérifiez s’il contient les renseignements requis par l’application.

Si vous décodez le jeton ou l’assertion, contient-il l’information attendue?

• Consultez les JWT avec JWT.io.
• Consultez les assertions SAML avec SAMLTool.io.

Si l’utilisateur connecté ne peut pas accéder à une autre application avec l’authentification unique

1. L’utilisateur essaie-t-il de se connecter à la deuxième application dans le même navigateur que celui utilisé lors de sa connexion initiale ?
2. Accédez à Paramètres du locataire > Avancé et vérifiez les paramètres de gestion des sessions de connexion. La deuxième tentative de connexion a-t-elle eu lieu avant l’expiration de ces délais ?
3. Vérifiez la valeur transmise dans le paramètre prompt de l’appel à /authorize.
4. La connexion utilisée pour se connecter à la première application est-elle activée pour la deuxième application ?
5. La deuxième application a-t-elle reçu toutes les informations nécessaires du profil utilisateur ?
6. Si vous utilisez un appareil mobile, vous devrez utiliser un flux basé sur le navigateur. Pour en savoir plus, consultez Meilleures pratiques.

Vérifiez les journaux de l’application

• Les journaux de votre application affichent-ils des erreurs?
• L’application a-t-elle reçu toutes les informations nécessaires, comme des groupes ou des attributs du profil utilisateur?

Problèmes de déconnexion

• Avez-vous ajouté vos URL de redirection de déconnexion à la liste des URL autorisées ? Si vous utilisez une URL de redirection dans un appel de déconnexion, elle doit être enregistrée dans les paramètres du locataire ou dans les paramètres de l’application.
• Si vous avez besoin d’une déconnexion fédérée, avez-vous ajouté le paramètre ?federated à l’appel de déconnexion ?
• Assurez-vous que l’URL de redirection de déconnexion est différente de l’URL de rappel de connexion.
• Faites en sorte que l’URL de redirection de déconnexion pointe vers une page anonyme (non protégée par authentification), afin que les redirections vers cette URL ne déclenchent pas immédiatement une connexion, ce qui pourrait semer la confusion chez les utilisateurs.