Skip to main content

​
Session behavior

Delegated sessions differ from a regular Auth0 session in several ways:
  • Authorization Code flow only. SAML, WS-Federation, and the Implicit flow are not supported for establishing a delegated session.
  • No refresh tokens. The offline_access scope is excluded from any token issued during a delegated session.
  • No interactive prompts. MFA, consent, and enrollment prompts (for example, passkey or MFA factor enrollment) cannot be satisfied during a delegated session. If one would be triggered, the request fails with interaction_required instead of prompting the user.
  • Existing sessions block delegated access. If an active Auth0 session already exists for the browser, the delegated session attempt fails with an error page asking the user to log out first. This applies to any active session on that domain — the subject user’s own session, or a previous delegated session established for a different user — not only a session belonging to the subject user. This is different from standard Native to Web SSO, which revokes the existing session and continues. To learn more, read Native to Web SSO and Sessions.
    The actor, for example, a support agent, must log out of a delegated session before a different delegated session can be established for another user on the same domain.
  • Ephemeral by default. The session cookie is set to non-persistent or discarded when the browser closes.
  • Fixed 2-hour session lifetime. Both the absolute and idle timeouts are hard-coded to 2 hours for delegated sessions and are not currently configurable. The issued access token shares this same 2-hour expiration.
  • Device binding. Delegated sessions always enforce IP-based device binding. This cannot be disabled or changed to ASN, unlike the configurable device binding used by standard Native to Web SSO. Delegated sessions honor is_token_endpoint_ip_header_trusted and auth0-forwarded-for for determining the trusted IP, the same as Native to Web SSO.
  • Single-level actor only. A Session Transfer Token accepts only one level of actor. Nested actors, which are allowed up to five levels deep for Custom Token Exchange access tokens, are rejected for Session Transfer Tokens.
  • Client user records are still written for delegated sessions. If your Action sets custom claims in ID tokens, they will also appear in /userinfo calls from the subject user’s own regular sessions.
  • User grants are not auto-created while session.actor is present, to avoid leaving behind permanent side effects of a delegated session.
  • Last login, login count, and last login IP are not updated.
  • Welcome emails are not sent.

​
Actions

event.session.actor is available in Post-Login Actions during a delegated session, containing the exact actor object passed to setActor() when the Session Transfer Token was issued.

​
Monitoring

Delegated sessions generate their own tenant log event types: Each of these log entries includes the actor’s sub in the log details for auditing. A warning (w) log is also emitted when a delegated session is blocked because the target client does not have allow_delegated_access enabled — see Configure the target web application.