Can Native-to-Web SSO be used after a device_sso token exchange?

Questions OAuth/OIDC
1

We are trying to combine Okta Native SSO (device_sso) with Native-to-Web SSO (interclient_access) in an Identity Engine mobile application.

Use case

Our mobile app performs native Okta authentication with:

openid profile email offline_access device_sso

We must retain device_sso for the app’s existing native SSO functionality.

After login, the mobile app needs to SSO into a trusted target OIDC web application. That target is integrated with Genesys Cloud, and we need the resulting authorization code to start an authenticated Messenger chat.

The mobile app does not have an Okta browser-session cookie, so we followed the Native-to-Web SSO documentation:

What works

If the original mobile login requests:

openid interclient_access

we can:

  1. Obtain the access-token and ID-token pair.

  2. Exchange them for a single-use interclient_token.

  3. Pass that token to the target app’s authorization request.

  4. Receive the expected authorization code.

This confirms that the origin-to-target trust mapping, application assignments and target authorization flow are working.

However, we cannot use this approach because we cannot remove device_sso, and device_sso and interclient_access cannot be requested together during our original login.

What we tried

We authenticate normally with:

openid profile email offline_access device_sso

We then use the returned device_secret and original ID token in a Token Exchange request, requesting:

openid interclient_access

Okta returns a fresh access-token and ID-token pair successfully.

We verified that:

  • The access token contains openid and interclient_access.

  • The access-token cid matches the ID-token aud.

  • Both tokens have the same issuer and issuance time.

  • The ID token’s at_hash matches the access token.

  • The ID token contains sid and ds_hash.

We then exchange this fresh pair for the single-use interclient_token, using the trusted target app as the audience.

That request fails with:

{
  "error": "access_denied",
  "error_description": "The requesting client app retrieved from session is different from the audience of the id_token."
}

We reproduced the same result using both the default custom authorization server and a separate custom authorization server.

Token Exchange is enabled on the origin application and authorization-server policy. The user is assigned to both applications, and the origin app is included in the target app’s Native-to-Web allowlist.

Questions

  1. Is it supported to obtain a Native-to-Web interclient_access token pair through a device_secret Token Exchange after an initial device_sso login?

  2. If it is supported, is there another parameter or configuration required to create the session expected by the subsequent interclient_token exchange?

  3. If it is not supported, what is the recommended way to retain device_sso while allowing the authenticated native app to SSO into a trusted target web app without another interactive browser login?

The direct interclient_access test succeeds, so the failure appears specific to obtaining the token pair through the device-secret exchange.

I can provide sanitized request parameters, decoded token payloads and relevant System Log events if needed.

2

From what you have described it sounds like the issue is not with the token exchange itself but with the Native to Web SSO flow expecting an interactive browser session tied to the original authentication. The device_secret exchange can issue new access/ID tokens, but it may not recreate the browser backed session that the interclient_token flow validates, which would explain the “requesting client app retrieved from session is different from the audience of the id_token” error. I have not seen documentation confirming that device_sso → Token Exchange → interclient_access is a supported chain. If your direct interclient_access login works but the exchanged tokens do not, this may simply be an unsupported combination.

3

Thanks—that may be the limitation, but Flow A (interclient_access at login → interclient token) works, while Flow B (device_sso login → device-secret exchange for valid interclient_access tokens → interclient token) fails; logically both should work unless Okta has a documented restriction and reason for this specific chain.