Passer au contenu principal

Avant de commencer

Pour utiliser la déconnexion par canal arrière, votre application doit répondre aux exigences suivantes :
  • Le point de terminaison d’URI de déconnexion OIDC par canal arrière de votre application doit être accessible sur Internet afin que votre locataire Auth0 puisse y accéder.
  • Les applications prêtes pour la production doivent utiliser TLS. Pour en savoir plus, consultez TLS (SSL) Versions and Ciphers.
  • L’application doit pouvoir stocker l’identifiant de session fourni (sid) et l’associer aux sessions utilisateur qu’elle crée. Nous recommandons aux applications de production d’utiliser un stockage de session persistant.
  • L’application doit pouvoir récupérer une session existante à partir du sid pendant le processus de déconnexion, sans utiliser de témoins côté client. Les témoins se trouvent dans le navigateur et sont inaccessibles au point de terminaison de rappel de déconnexion.

​
Disponibilité

La déconnexion OIDC par canal arrière est offerte à tous les clients du forfait Enterprise. Vérifiez le point de terminaison de métadonnées standard OIDC /.well-known/* pour déterminer si votre application répond aux exigences. 
GET https://acme.eu.auth0.com/.well-known/openid-configuration

HTTP 200
{ ..., "backchannel_logout_supported": true, 
  "backchannel_logout_session_supported": true }

​
Restrictions de la déconnexion par canal arrière

Les URL de déconnexion par canal arrière sont invoquées sur des points de terminaison accessibles publiquement et doivent respecter certaines restrictions :
  1. Vous devez utiliser le protocole HTTPS. Le protocole HTTP non chiffré ou tout autre protocole n’est pas autorisé.
  2. Vous ne devez pas utiliser de sous-domaines Auth0. Voici quelques sous-domaines Auth0 :
    • auth0.com
    • auth0app.com
    • webtask.io
    • webtask.run
  3. Nous ne recommandons pas d’utiliser des adresses IP sans domaine. Pour utiliser la déconnexion par canal arrière, les adresses IP doivent être publiques. Les adresses IP provenant de plages internes, réservées ou de bouclage ne sont pas autorisées.

​
Configurer Auth0

Enregistrez votre application pour recevoir des jetons de déconnexion via ou la .

​
Inscrire des applications

  1. Accédez à Auth0 Dashboard > Applications.
  2. Choisissez l’application que vous souhaitez enregistrer.
  3. Sélectionnez l’onglet Settings.
  4. Dans OpenID Connect déconnexion par canal arrière > déconnexion par canal arrière URI, ajoutez l’URI de déconnexion de l’application qui recevra les logout_tokens
  5. Une fois terminé, sélectionnez Save Changes.
    Auth0 Dashboard > Applications > Settings

​
Désinscrire des applications

La désinscription de votre application empêche le service de suivre les nouvelles connexions et d’envoyer des événements de déconnexion. Le service supprime les événements de déconnexion en attente une fois votre application désinscrite.Pour désinscrire votre application, supprimez l’URL de déconnexion par canal arrière.
  1. Accédez à Auth0 Dashboard > Applications.
  2. Choisissez l’application que vous souhaitez enregistrer.
  3. Sélectionnez l’onglet Settings.
  4. Dans OpenID Connect déconnexion par canal arrière > déconnexion par canal arrière URI
  5. Supprimez l’URL de déconnexion par canal arrière.
  6. Une fois terminé, sélectionnez Save Changes.
    Auth0 Dashboard > Applications > Settings
À des fins d’audit, le service consigne toujours l’ajout ou la suppression des URL de déconnexion par canal arrière sous forme d’API Operation Event dans les journaux du locataire Auth0. Pour en savoir plus, consultez Logs.

​
Configurez votre application

Une fois la déconnexion par canal arrière configurée dans l’Auth0 Dashboard ou via la Management API, configurez votre application pour utiliser le service en fonction de la technologie ou du framework.
  1. Implémentez l’authentification de l’utilisateur final selon le type de votre application.
    1. Les utilisateurs finaux doivent pouvoir se connecter à l’application, et une session doit être créée.
    2. Un jeton d’identité doit être émis par Auth0 et être accessible dans le back-end de l’application pour un traitement ultérieur.
  2. Étendez le processus de connexion afin d’enregistrer les revendications sid et, au besoin, sub après la validation du jeton d’identité.
    1. Ces revendications doivent être associées à la session active de l’application.
    2. Les fonctions de gestion de session doivent pouvoir récupérer une session précise à partir de la valeur sid.
  3. Configurez le point de terminaison de la déconnexion par canal arrière :
    1. Le point de terminaison doit accepter uniquement les requêtes HTTP POST.
    2. Extrayez le paramètre logout_token et validez-le comme un JWT standard conformément à la spécification.
    3. Vérifiez que le jeton contient une revendication events avec une valeur d’objet JSON et un membre nommé http://schemas.openid.net/event/backchannel-logout.
    4. Vérifiez que le jeton contient les revendications sid et/ou sub.
    5. Vérifiez que le jeton ne contient PAS la revendication nonce. Cette exigence vise à prévenir les abus en distinguant le jeton de déconnexion du jeton d’identité.
    6. Une fois le jeton validé, récupérez la session correspondant à la valeur sid et/ou sub reçue, puis mettez-y fin. Le processus exact de terminaison de la session de l’application dépend des détails de l’implémentation. Par exemple, il peut être nécessaire de transmettre cet événement au front-end.

​
Exemple de requête de déconnexion OIDC par canal arrière

Charge utile du jeton encodé :
cURL
POST /backchannel-logout HTTP/1.1
Host: rp.example.org
Content-Type: application/x-www-form-urlencoded

logout_token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImdwY3ZFT0FPREE2T3pXRmw3ODVxbCJ9.eyJpc3MiOiJodHRwczovL2FydGV4LWRldi5ldS5hdXRoMC5jb20vIiwic3ViIjoiYXV0aDB8NjAyZTkzZGI4M2ZhNmYwMDc0OWEyM2U2IiwiYXVkIjoiVHVoTkx2N3VsWEQzUmZ5TGxTTWJPdnN6endKSkZQcE8iLCJpYXQiOjE2OTgxNjA5MjgsImV4cCI6MTY5ODE2MTA0OCwianRpIjoiNDRhOTEyMTUtZGZiNC00ZGZlLWExZWItZmNhZmE5MTFkZWJhIiwiZXZlbnRzIjp7Imh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvZXZlbnQvYmFja2NoYW5uZWwtbG9nb3V0Ijp7fX0sInRyYWNlX2lkIjoiODFiMzM2YTk0YTRhNTcwNyIsInNpZCI6IjM3NVVJcF9JRDVtQ1RDbEllQkVIcFhmR3dxNTF0Rl9MIn0.aEoAL_U-EPlf3f7Fup-bu7Yv0S0GOnrkL8Njd6j6UNqZcr5VrWWFf3CWvkRi7Cm6wMgU2qIMhb7643ca8-ajR7zHlMu0Z3r-gfd2D1xudKLyUSC3v2D5WJZz5I8xMZ_LWtIN2W3l4SQFO9MgK_7F3x0WIWXo9KPC9tgOaOLPnsiv__MutM1ZakoCsJPddl5gVM4TYtHOue6WM7SOXZNa3SSiv57YQOX2KNCL7sWmZp_J1OXKy8lsgkNFqiOVwu39p4sgjKYEXQU0G-I0yY_aeNbnlnxFG6OuxaDt_zwg6AvKglLSNGqrrvzy4GsYJi5HMGZ1GsSs7rQLg7Iuu6JM-A
Le jeton expire après 2 minutes (120 s).
Charge utile du jeton décodé :
JSON
{
   "iss": "https://artex-dev.eu.auth0.com/",
   "sub": "auth0|602e93db83fa6f00749a23e6",
   "aud": "TuhNLv7ulXD3RfyLlSMbOvszzwJJFPpO",
   "iat": 1698160928,
   "exp": 1698161048,
   "jti": "44a91215-dfb4-4dfe-a1eb-fcafa911deba",
   "events": {
         "http://schemas.openid.net/event/backchannel-logout": {}
   },
   "trace_id": "81b336a94a4a5707",
   "sid": "375UIp_ID5mCTClIeBEHpXfGwq51tF_L"
}

​
Réponses attendues

  • HTTP 200 : Confirme la déconnexion de l’utilisateur de l’application concernée.
  • HTTP 400 : Indique une requête incorrecte. La requête n’est pas comprise ou le jeton n’a pas pu être validé. Auth0 consigne le problème dans les journaux du locataire, mais n’effectue pas d’autres requêtes pour cette session.

​
Dépannage

​
L’application n’a pas reçu les événements de déconnexion

Si votre application n’a pas reçu de requête de déconnexion après un événement de déconnexion.
  1. Assurez-vous que votre application dispose d’une URL de déconnexion par canal arrière enregistrée dans Auth0 Dashboard.
  2. Assurez-vous que l’URL de déconnexion par canal arrière est accessible depuis le locataire Auth0.
  3. Assurez-vous qu’une session valide est établie. L’utilisateur final doit se connecter à cette application en particulier via Auth0.
    Les applications reçoivent des événements de déconnexion uniquement si les utilisateurs finaux se connectent à cette application en particulier avec Auth0. Si l’utilisateur final se connecte à d’autres applications, les événements de déconnexion ne sont pas déclenchés.
  4. Vérifiez les journaux du locataire Auth0 pour voir s’ils contiennent des messages indiquant un échec de remise des messages de déconnexion.
  5. Assurez-vous que la déconnexion est déclenchée via le point de terminaison de déconnexion standard. Les autres événements ne déclenchent pas les événements de déconnexion.
  6. Si possible, vérifiez si des requêtes sont bloquées dans les journaux du serveur web ou du pare-feu de l’application.

​
Je ne trouve pas les journaux du locataire pour la déconnexion OIDC par canal arrière

Cette fonctionnalité sera déployée progressivement auprès de tous les locataires à compter du 3 octobre 2023. Vous pourriez encore recevoir les codes d’événement des journaux du locataire sslo pour oidc_backchannel_logout_succeeded ou fslo pour oidc_backchannel_logout_failed.

​
L’application cliente ne peut pas vérifier le jeton de déconnexion reçu

Si la transaction échoue toujours avec une erreur 400 :
  1. Vérifiez si le jeton est un JWT standard encodé en Base64. Certains serveurs Web peuvent tronquer les paramètres longs. Pour en savoir plus, consultez Signing Algorithms.
  2. Si possible, capturez un jeton et vérifiez qu’il s’agit bien d’un JWT. Utilisez une source de confiance, comme JWT.IO.
  3. Assurez-vous que la fonction de vérification récupère dynamiquement la clé de signature du locataire par l’intermédiaire de JSON Web Key Sets (JWKS).
    Nous ne recommandons pas de coder en dur une clé statique. Si votre configuration exige qu’une clé statique soit codée en dur, assurez-vous qu’elle contient la clé publique la plus récente du locataire Auth0.

​
Erreurs de délai d’expiration de la réponse

Auth0 attendra cinq secondes que l’URL de déconnexion OIDC par canal arrière de l’application réponde. Après ce délai, l’événement « Failed OIDC Back-Channel Logout request » sera consigné dans les journaux du locataire avec une description de réponse vide.

​
En savoir plus