Skip to main content
Native to Web SSO is currently available in Early Access. To use this feature, you must have an Enterprise plan. By using this feature, you agree to the applicable Free Trial terms in Okta’s Master Subscription Agreement. To learn more about Auth0’s product release cycle, read Product Release Stages.

​
Configure Native to Web SSO

To use Native to Web (SSO), configure your native and web (Single Page App or Regular Web App) to create and manage sessions with the Auth0 . You need an access token to use the Management API or Auth0 CLI. To configure Native to Web SSO, you need to create and manage session_transfer_tokens and configure your native and web applications.
Native to Web SSO supports the following SDKs: Auth0 Android SDK, Auth0 Swift SDK, and Auth0 React Native SDK.Native to Web SSO support is available in the following tools: Auth0 Deploy CLI. Auth0 Terraform Provider and Auth0 CLI.Native to Web SSO supports any authentication flow that returns a refresh token, such as Resource Owner Password Flow and Authorization Code Flow with Proof Key for Code Exchange.

​
Create and manage Session Transfer Tokens

The first Management API call allows your native and web Applications to:
  • Create and manage session_transfer_tokens
  • Create sessions in a web browser via cookies or a URL parameter
  • Bind the session to a user’s device through an IP address or ASN
For existing applications, make a PATCH call to the Update a Client endpoint. To create a new application, make a POST call to the Create a Client endpoint: 
{
  "session_transfer": {
    "can_create_session_transfer_token": false,
    "allowed_authentication_methods": ["cookie", "query"],
    "enforce_device_binding": "ip", // also "none" or "asn",
    "allow_refresh_token": false,
    "enforce_cascade_revocation": true,
    "enforce_online_refresh_tokens": true
  }
}

​
Configure native applications

Once a user is authenticated, Auth0 returns an Access token, and ID token, and (optionally) a Refresh token. You can configure your native application to exchange a for a Session Transfer Token. If your web application does not support cookie injection, your native application also needs to configure your web application’s Login URI to inject the Session Transfer Token as a URI parameter.
  • Update your native application using your Management API with the Update a Client endpoint:
  • Update your native application using Auth0 CLI:

​
Configure web applications

Before you enable Session Transfer Token, make sure you have configured your web application’s Application Login URI to handle extra parameters. To learn more about URIs, read Application Settings.
  • Update your web application using the Management API Access Token with the Update a Client endpoint:
  • Update your web application using Auth0 CLI:

​
Implement Native to Web SSO

Native to Web Single SSO provides a seamless user experience transitioning authenticated users from your native application to your web application. To facilitate this, your native application needs to exchange a refresh token for a Session Transfer Token and send the Session Transfer Token, through a URL or cookie, to your web application to authorize the session.
  • If allow_refresh_token is disabled in the client but the application requests offline_access, Auth0 will not issue a refresh_token but the authentication will still work.
  • If refresh token rotation is enabled, Auth0 returns a new refresh_token in the token exchange call. The refresh token exchange should happen immediately before your code opens the web application.

​
In your native application

​
Step 1: Exchanging a Refresh Token for a Session Transfer Token

Use the /token endpoint with your native application to exchange the refresh token for a Session Transfer Token.
  • Exchange a refresh token for a session transfer token using Swift, Android, or React Native SDKs:
credentialsManager.ssoCredentials { result in
    switch result {
    case .success(let ssoCredentials):
        print("Obtained SSO credentials: \(ssoCredentials)")
    case .failure(let error):
        print("Failed with: \(error)")
    }
}

// Or, using async/await

do {
    let ssoCredentials = try await credentialsManager.ssoCredentials()
    print("Obtained SSO credentials: \(ssoCredentials)")
} catch {
    print("Failed with: \(error)")
}
  • Exchange a refresh token for a session transfer token using HTTP:
These samples use placeholder variables for dynamic variables. Replace the placeholders using your Auth0 domain, client_id and an existing refresh_token.
The Auth0 tenant returns a single-use and short-lived (1-minute lifetime) session_transfer_token. 
{
    "access_token": "{session_transfer_token}",
    "issued_token_type": "urn:auth0:params:oauth:token-type:session_transfer_token",
    "token_type": "N_A",
    "expires_in": 60
}
If refresh token rotation is enabled, the exchange will also return a refresh token.If you requested an ID Token during authentication, this call will also return an ID Token.
There are two options to send the  session_transfer_token to your web application based on the configured allowed_authentication_methods.
Option 1: Send the session_transfer_token as a cookie
If your web application using WebView or browser supports cookie injection, you can configure your native application to:
  • Add the session_transfer_token into a cookie.
  • Open the web application using WebView or browser.
  • Log the web application to your Auth0 tenant or . As the session_transfer_token is included in the cookie, the user is not prompted for first-factor authentication.
Option 2: Send the session_transfer_token as a URL parameter
If your web application does not support cookie injection, you can configure your native application using URL parameters to:
  • Add the session_transfer_token as a URL parameter.
  • Open the web application using  WebView or browser.
  • Log the web application appending the session_transfer_token as a URL parameter to the /authorize endpoint. The Auth0 tenant authenticates the user without requiring first-factor authentication, as the session_transfer_token is valid and trusted

​
In your web application

When the Session Transfer Token is sent as a cookie, no further configuration is needed as the browser sends the cookie in the /authorize endpoint request.
Implement Native to Web Web Single SSO in your web application using URL parameters by:

​
Option 1: Add the Session Transfer Token in your web application request

From the application login URL, redirect to the /authorize endpoint when the session_transfer_token is sent as a URL parameter.

​
Option 2: Add the Session Transfer Token to web applications using Auth0 SDKs

Auth0 SDKs do not support Native to Web Single SSO automatically and they will not include the session_transfer_token in the /authorize endpoint request. Below are examples of web applications using Auth0 SDKs to redirect the session_transfer_token in the /authorize endpoint request:
Node (Express.js)
If your web application uses Express.js or the Auth0 Express SDK, you can use the code below to add middleware support for session_transfer_token.
javascript
const baseConfig = {
  authRequired: false,
  auth0Logout: true
};

// Extending the middleware to auto detect session_transfer_token
app.use((req, res, next) => {
  const { session_transfer_token } = req.query;

  // Create a new config for each request to avoid state leakage
  const config = { ...baseConfig };

  if (session_transfer_token) {
    config.authorizationParams = {
      session_transfer_token,
    };
  }

  auth(config)(req, res, next);
});
Auth0 SPA SDK (@auth0/auth0-spa-js)
If your web application uses the Auth0 SPA SDK, you can pass the session_transfer_token to loginWithRedirect() via authorizationParams.
typescript
import { Auth0Client } from '@auth0/auth0-spa-js';

const auth0 = new Auth0Client({
  domain: '{yourDomain}',
  clientId: '{yourClientId}',
});

// Get session_transfer_token from URL query params (passed from native app)
const urlParams = new URLSearchParams(window.location.search);
const sessionTransferToken = urlParams.get('session_transfer_token');

// Use loginWithRedirect with the session_transfer_token
if (sessionTransferToken) {
  await auth0.loginWithRedirect({
    authorizationParams: {
      session_transfer_token: sessionTransferToken,
      redirect_uri: window.location.origin,
    },
  });
}
Auth0 React SDK (@auth0/auth0-react)
If your web application uses the Auth0 React SDK, you can use loginWithRedirect from the useAuth0 hook to pass the session_transfer_token.
typescript
import { useEffect } from 'react';
import { useAuth0 } from '@auth0/auth0-react';

function App() {
  const { loginWithRedirect, isAuthenticated, isLoading } = useAuth0();

  useEffect(() => {
    if (isLoading || isAuthenticated) return;

    const urlParams = new URLSearchParams(window.location.search);
    const sessionTransferToken = urlParams.get('session_transfer_token');

    if (sessionTransferToken) {
      loginWithRedirect({
        authorizationParams: {
          session_transfer_token: sessionTransferToken,
        },
      });
    }
  }, [loginWithRedirect, isLoading, isAuthenticated]);

  return <div>...</div>;
}
SAML and WS-Federation
If your web application uses or service provider and Auth0 as the , you can send the session_transfer_token as an URL parameter to the Auth0 /authorize endpoint and the redirect_uri is the SAML or WS-Fed sign-in URL.

​
Native to Web SSO with Organizations

Native to Web SSO supports Organizations. When a user authenticates with an organization in your native application, the session transfer token includes the organization context.
When using Organizations with Native to Web SSO, the organization parameter in the web application’s /authorize request must match the organization associated with the session transfer token. If there is a mismatch, authentication will fail and the user will be prompted to log in again.
To use Organizations with Native to Web SSO:
  1. Authenticate the user in your native application with an organization:
javascript
// Native app login with organization
await authorize({
  organization: 'org_abc123',
  scope: 'openid profile email offline_access'
});
  1. When redirecting to the web application, include the same organization in the /authorize request:
bash
https://{yourDomain}/authorize?
  client_id={yourWebClientId}&
  redirect_uri={yourRedirectUri}&
  response_type=code&
  organization=org_abc123&
  session_transfer_token=YOUR_SESSION_TRANSFER_TOKEN
If the organization in the /authorize request does not match the organization in the session transfer token, the session transfer token is rejected and the user is redirected to the login page to re-authenticate. A warning log is emitted in your tenant logs with the event description “Single Sign-On failed: Session Transfer Token organization mismatch detected.”

​
Session Transfer Token with Actions

Using session_transfer_token with Actions allows you to configure post-authentication risk detection and response capabilities to enhance user protection. To facilitate this, the post-login Action object event.session_transfer_token provides relevant information including unique client_id, scope, request information such as ip, asn, user_agent and geoip information such as, cityName, countryCode among others. To learn more, read Actions Triggers: post-login - Event Object. The Action code below allows you to dynamically reject a transaction based on geolocation information:
javascript
/**
* Handler that will be called during the execution of a PostLogin flow.
*
* @param {Event} event - Details about the user and the context in which they are logging in.
* @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login.
*/
exports.onExecutePostLogin = async (event, api) => {
   if(
     event.session_transfer_token &&
     event.session_transfer_token.request.geoip.countryCode !== event.request.geoip.countryCode
     ) {
     api.access.deny("Network mismatch detected")
   }
};

​
Access Parent Refresh Token Metadata

Native to Web SSO allows you to access metadata from the parent refresh token that was used to initiate the SSO flow. This enables you to pass contextual information collected in the native application (such as device integrity, risk signals, or custom context) into the web session created from the session_transfer_token. Auth0 exposes this information in Post Login Actions via the event.session.session_transfer.parent_refresh_token.metadata object. This enables secure, standardized propagation of metadata between platforms.
Example Use Case: A mobile app collects risk data (device score, location, etc.) and stores it in the refresh token’s metadata. When the native app initiates a Native to Web SSO flow, that metadata is automatically available in the corresponding web session via Actions.
The Action code below allows you to perform conditional access logic based on device trust metadata from the native application:
javascript
/**
* Handler that will be called during the execution of a PostLogin flow.
*
* @param {Event} event - Details about the user and the context in which they are logging in.
* @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login.
*/
exports.onExecutePostLogin = async (event, api) => {
  // Access metadata from the parent refresh token (native app)
  const parentMetadata = event.session?.session_transfer?.parent_refresh_token?.metadata;

  if (parentMetadata) {
    const deviceTrustLevel = parentMetadata.device_trust;

    if (deviceTrustLevel !== 'high') {
      api.access.deny("Device trust level insufficient.");
    }

    // You can also add claims based on native app context
    if (parentMetadata.subscription_tier) {
      api.idToken.setCustomClaim('subscription_tier', parentMetadata.subscription_tier);
    }
  }
};

​
Monitoring

You can monitor the Native to Web SSO activity by reviewing the Tenant logs.

​
Token exchange logs

  • sertft : Successful Refresh Token exchange. This log will correspond to a Native to Web SSO exchange when the audience field is "audience":"urn:$auth0Domain:session_transfer"
  • fertft: Failed Refresh Token exchange. This log will correspond to a Native to Web SSO exchange when the audience field is "audience": "urn:$auth0Domain:session_transfer"

​
Session transfer validation warning logs

Auth0 emits warning logs (w) when session transfer token validation fails during the /authorize request. These logs help you troubleshoot Native to Web SSO issues:
Event DescriptionCause
Single Sign-On failed: Session Transfer Token not found or expired. This may indicate token reuse or expiration.The session transfer token was not found, has already been used, or has expired (tokens are single-use and expire after 1 minute).
Single Sign-On failed: Session Transfer Token device binding validation failed due to IP/ASN mismatch.The IP address or ASN of the web request does not match the device binding configured for the session transfer token.
Single Sign-On failed: Session Transfer Token organization mismatch detected.The organization parameter in the /authorize request does not match the organization in the session transfer token.
Single Sign-On failed: Session Transfer Token user mismatch detected.A pre-existing Auth0 session belongs to a different user than the session transfer token.
Single Sign-On failed: Parent refresh token not found. Session Transfer Token won't be used for session establishment.The parent refresh token used to create the session transfer token has been revoked or deleted.