Configuration de déconnexion du canal d’appui OIDC

La déconnexion du canal d’appui OIDC est disponible pour tous les clients du plan Enterprise. Vous devez vérifier le point de terminaison de métadonnées /.well-known/* de la norme OIDC pour déterminer si votre application satisfait aux exigences.

GET https://acme.eu.auth0.com/.well-known/openid-configuration

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

Les URL de déconnexion du canal d’appui sont appelées sur des points de terminaison exposés au public et doivent respecter certaines restrictions :

1. Vous devez utiliser les protocoles HTTPS. Les protocoles HTTP non chiffrés ou d’autres protocoles ne sont pas autorisés.

2. Vous ne devez pas utiliser de sous-domaines Auth0. Voici plusieurs sous-domaines Auth0 :

   • auth0.com

   • auth0app.com

   • webtask.io

   • webtask.run

3. Nous ne recommandons pas l’utilisation d’adresses IP sans domaine. Les adresses IP doivent être publiques pour utiliser la déconnexion par canal d’appui. Les adresses IP à portée interne, réservée ou de boucle ne sont pas autorisées.

Enregistrez votre application pour recevoir des jetons de déconnexion via Auth0 Dashboard ou Management API.

PATCH /api/v2/clients/{id}
"oidc_logout": {
  "backchannel_logout_urls": ["http://acme.eu.auth0.com/events"]
}

PATCH https://acme.eu.auth0.com/api/v2/clients/{id}
{
  "oidc_logout": {
    "backchannel_logout_urls": []
  }
}

Une fois que vous avez configuré la déconnexion par canal d’appui via Auth0 Dashboard ou Management API, configurez votre application pour utiliser le service en fonction de la technologie ou du cadre d'applications.

1. Implémentez l’authentification de l’utilisateur final en fonction de votre type d’application.

   1. Les utilisateurs finaux doivent pouvoir se connecter à l’application et une session doit être créée.

   2. Un jeton d’ID doit être émis par Auth0 et doit être accessible dans le système dorsal de l’application pour un traitement ultérieur.

2. Étendez le processus de connexion pour sauvegarder le sid et, éventuellement, les sous-demandes après la validation du jeton d’ID.

   1. Ces demandes doivent être sauvegardées en fonction de la session d’application en cours.

   2. Les fonctions de gestion de session doivent être en mesure de récupérer une session spécifique à l’aide de la valeur sid.

3. Configurez le point de terminaison de déconnexion du canal d’appui :

   1. Le point de terminaison doit traiter uniquement les requêtes HTTP POST.

   2. Extrayez le paramètre logout_token et validez-le en tant que JWT standard conformément à la spécification.

   3. Vérifiez que le jeton contient une demande d’événement 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 demandes sid et/ou sub.

   5. Vérifiez que le jeton ne contient PAS la demande nonce. Cela est nécessaire pour éviter les abus en distinguant le jeton de déconnexion du jeton d’ID.

   6. Une fois le jeton validé, récupérez la session correspondant à la valeur sid et/ou sub reçue et mettez-y fin. Le processus exact de clôture de la session de l'application dépend des détails de la mise en œuvre. Par exemple, cet événement peut devoir être communiqué au programme frontal.

Charge utile codée de jeton :

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

Charge utile décodée de jeton :

{
  "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"
}

• HTTP 200 :  ce protocole confirme la déconnexion de l’utilisateur de l’application spécifique.

• HTTP 400 : indique une demande incorrecte. La demande n’est pas comprise ou la validation du jeton a échoué. Auth0 enregistre le problème dans les journaux du locataire mais ne tente pas d’autres demandes pour cette session.

Votre application n’a pas reçu de demande 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 d'appui enregistrée dans Auth0 Dashboard.

2. Assurez-vous que l’URL de déconnexion par canal d'appui est accessible depuis le locataire Auth0.

3. Assurez-vous qu’une session valide est établie. L’utilisateur final doit se connecter à votre application spécifique via Auth0.

   Les applications reçoivent des événements de déconnexion seulement si les utilisateurs finaux se connectent à cette application spécifique 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 la présence de messages concernant l'échec de la transmission des messages de déconnexion dans les journaux du locataire Auth0.

5. Assurez-vous que la déconnexion est déclenchée par le point de terminaison standard de déconnexion. D’autres événements ne déclenchent pas d’événements de déconnexion.

6. Si possible, vérifiez si des demandes ont été bloquées sur le serveur Web et/ou dans les journaux du pare-feu de l’application.

7. Confirmez que vous utilisez un certificat valide (non auto-signé) dans le point de terminaison de déconnexion du canal d'appui.

Cette fonctionnalité est progressivement mise à disposition de tous les locataires depuis le 3 octobre 2023. Vous pouvez toujours recevoir des codes d’événements de journalisation de locatairesslo pour oidc_backchannel_logout_succeeded ou fslo pour oidc_backchannel_logout_failed.

Si la transaction échoue toujours avec une erreur 400 :

1. Vérifiez si le jeton est un JWT standard codé en base64. Certains serveurs web peuvent tronquer les paramètres longs. Pour en savoir plus, consultez Algorithmes de signature.

2. Si possible, capturez un jeton et vérifiez qu’il s’agit d’un JWT. Utilisez une source vérifiée, comme JWT.IO.

3. Assurez-vous que la fonction de vérification récupère la clé de connexion du locataire dynamiquement via les JSON Web Key Sets (ensembles de clés JSON Web) (JWKS).

   Nous ne recommandons pas les clés statiques codées en dur. Si votre configuration nécessite une clé statique codée en dur, assurez-vous que la configuration contient la clé publique la plus récente du locataire Auth0.

Auth0 attendra cinq secondes pour que l’URL de déconnexion par canal d'appui OIDC de l’application réponde. Passé ce délai, un « Échec de requête de déconnexion par canal d’appui OIDC » est enregistré dans les journaux du locataire, avec une description de réponse vide.

• Vérifier les problèmes de connexion et de déconnexion
• Déconnexion des utilisateurs d’Auth0 avec le point de terminaison OIDC
• Déconnecter l’utilisateur de l’application
• Déconnecter des utilisateurs des fournisseurs d’identité