メインコンテンツへスキップ
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, review 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 and Auth0 Swift 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 or Android 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. 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 config = {
  authRequired: false,
  auth0Logout: true
};

// Default Middleware with no customizations
// app.use(auth(config));

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

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

  auth(config)(req, res, next);
});
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.

​
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")
   }
};

​
Monitoring

You can monitor the Native to Web SSO activity by reviewing the Tenant 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"