Skip to main content

​
Comportement des sessions

Les sessions déléguées se distinguent d’une session Auth0 standard à plusieurs égards :
  • Flux de code d’autorisation uniquement. SAML, WS-Federation et le flux Implicit ne sont pas pris en charge pour établir une session déléguée.
  • Aucun jeton d’actualisation. La portée offline_access est exclue de tout jeton émis pendant une session déléguée.
  • Aucune invite interactive. Les invites MFA, de consentement et d’inscription (par exemple, l’inscription d’une passkey ou d’un facteur MFA) ne peuvent pas être traitées pendant une session déléguée. Si l’une d’elles devait être déclenchée, la requête échoue avec interaction_required au lieu d’inviter l’utilisateur.
  • Les sessions existantes bloquent l’accès délégué. Si une session Auth0 active existe déjà dans le navigateur, la tentative d’établir une session déléguée échoue et affiche une page d’erreur demandant à l’utilisateur de se déconnecter d’abord. Cela s’applique à toute session active sur ce domaine — la session de l’utilisateur concerné ou une session déléguée précédente établie pour un autre utilisateur — et pas seulement à une session appartenant à l’utilisateur concerné. Cela diffère du SSO Native to Web standard, qui révoque la session existante et poursuit le processus. Pour en savoir plus, consultez Native to Web SSO and Sessions.
    L’acteur, par exemple un agent de soutien, doit se déconnecter d’une session déléguée avant qu’une autre session déléguée puisse être établie pour un autre utilisateur sur le même domaine.
  • Éphémère par défaut. Le cookie de session est non persistant ou supprimé à la fermeture du navigateur.
  • Durée de session fixe de 2 heures. Les délais d’expiration absolu et d’inactivité sont tous deux codés en dur à 2 heures pour les sessions déléguées et ne sont actuellement pas configurables. Le jeton d’accès émis a la même expiration de 2 heures.
  • Liaison d’appareil. Les sessions déléguées appliquent toujours une liaison d’appareil fondée sur l’adresse IP. Elle ne peut pas être désactivée ni remplacée par une liaison basée sur l’ASN, contrairement à la liaison d’appareil configurable utilisée par le SSO Native to Web standard. Les sessions déléguées respectent is_token_endpoint_ip_header_trusted et auth0-forwarded-for pour déterminer l’adresse IP approuvée, comme le SSO Native to Web.
  • Un seul niveau d’acteur. Un Jeton de transfert de session n’accepte qu’un seul niveau d’acteur. Les acteurs imbriqués, autorisés jusqu’à cinq niveaux de profondeur pour les jetons d’accès Custom Token Exchange, sont rejetés pour les Jetons de transfert de session.
  • Les enregistrements d’utilisateurs clients sont tout de même créés pour les sessions déléguées. Si votre Action définit des revendications personnalisées dans des jetons ID, elles apparaîtront également dans les requêtes /userinfo provenant des sessions ordinaires de l’utilisateur concerné.
  • Les autorisations utilisateur ne sont pas créées automatiquement lorsque session.actor est présent, afin d’éviter de laisser des effets secondaires permanents après une session déléguée.
  • La dernière connexion, le nombre de connexions et l’adresse IP de la dernière connexion ne sont pas mis à jour.
  • Les courriels de bienvenue ne sont pas envoyés.

​
Actions

event.session.actor est disponible dans les Actions post-login lors d’une session déléguée et contient l’objet actor exact transmis à setActor() lors de l’émission du jeton de transfert de session.

​
Surveillance

Les sessions déléguées génèrent leurs propres types d’événements dans le journal du tenant : Chacune de ces entrées de journal inclut le sub de l’acteur dans les détails du journal à des fins d’audit. Un journal d’avertissement (w) est également généré lorsqu’une session déléguée est bloquée parce que le client cible n’a pas activé allow_delegated_access — consultez Configurer l’application Web cible.