> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-feat-session-delegation.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Delegated Session Behavior and Monitoring

> Understand how delegated sessions behave differently from regular sessions, their side effects, Actions support, and how to audit them in tenant logs.

export const ReleaseStageNotice = ({feature, stage, plans, contact, terms}) => {
  const stageTextMap = {
    "beta": "Beta",
    "ea": "Early Access"
  };
  const stageText = stageTextMap[stage] || "a product release stage";
  const prsLink = "/docs/troubleshoot/product-lifecycle/product-release-stages";
  const linkify = (text, url) => {
    return <a href={url} target="_blank" rel="noreferrer" class="link">{text}</a>;
  };
  const includeDetails = (plans, contact, terms) => {
    const hasDetails = terms || plans || contact;
    if (!hasDetails) return null;
    return <span data-as="p">
            {plans && <>This feature is available for {linkify(`${plans} plans`, "https://auth0.com/pricing")}. </>}
            {contact && "To participate, contact " + contact + ". "}
            {terms && <>By using this feature, you agree to the applicable Free Trial terms in Okta's {linkify("Master Subscription Agreement", "https://www.okta.com/legal")}.</>}
        </span>;
  };
  return <Warning>
            <span data-as="p">
                <strong>The {feature} feature is in {linkify(stageText, prsLink)}.</strong>
            </span>

            {includeDetails(plans, contact, terms)}
        </Warning>;
};

<ReleaseStageNotice feature="Session Delegation" stage="ea" plans="B2C Professional, B2B Professional, and Enterprise" terms="true" />

## 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](/docs/authenticate/single-sign-on/native-to-web/native-to-web-sso-and-sessions).

  <Callout icon="file-lines" color="#0EA5E9" iconType="regular">
    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.
  </Callout>
* **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](/docs/customize/actions/explore-triggers/post-login) 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](/docs/deploy-monitor/logs) event types:

| Event       | Description                                                           |
| ----------- | --------------------------------------------------------------------- |
| `sdel`      | Successful Delegated Login.                                           |
| `sdeleacft` | Successful Delegated Exchange of Authorization Code for Access Token. |
| `fdeleacft` | Failed Delegated Exchange of Authorization Code for Access Token.     |
| `sdelsa`    | Successful Delegated Silent Authentication.                           |
| `fdelsa`    | Failed Delegated Silent Authentication.                               |

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](/docs/authenticate/single-sign-on/session-delegation/configure-session-delegation#configure-the-target-web-application).