Native Android PKCE returns wrong access-token audience despite explicit audience and active user-delegated grant

Hello Auth0 Community,

I’m investigating unexpected access token audience behavior in a native Android application using Auth0 Authorization Code Flow with PKCE (S256).

The application needs separate access tokens for two custom APIs.

For illustration, their identifiers are:

  • API A: https://api.example.com

  • API B: https://consumer-api.example.com

All identifiers above are placeholders.

Configuration

  • Application type: Native, first-party

  • Both APIs are registered as Resource Servers

  • Signing algorithm: RS256

  • API Access Policy: Per-app authorization

  • The Native application has an active user-delegated access entry for API B

  • API B defines no custom permissions; the dashboard displays 0/0 permissions granted

  • No custom Post Login Actions or claim mappings

  • Tenant Default Audience is empty

  • Callback URLs and identity-provider connections are configured

Observed behavior

The application explicitly requests API B using the audience parameter in /authorize, together with the correct client ID, redirect URI, scopes, state, nonce, and PKCE challenge.

The authorization completes successfully and the code is exchanged at /oauth/token.

However, the returned access token does not contain API B’s audience.

The JWT signature, issuer, subject, and expiration were successfully checked. The application rejects the token because the audience does not match the requested API.

The same behavior was reproduced after rebuilding the application and repeating the authorization.

Questions

  1. Under Per-app authorization, is an active user-delegated client grant with zero custom API permissions sufficient to obtain an access token for that API?

  2. Is there an additional API Access Policy or Native application setting required for Auth0 to honor the requested audience?

  3. If Authorization Code + PKCE completes successfully but the access token has a different audience, what is the recommended way to diagnose whether the result is caused by the grant policy, an OAuth request parameter, or token issuance behavior?

  4. Should the audience be specified only in /authorize, or can including it again in /oauth/token affect the resulting access token?

We want to preserve least-privilege access and avoid adding unnecessary scopes, enabling unrestricted access, or changing the tenant-wide Default Audience.

Any guidance on the relevant configuration or a reliable diagnostic procedure would be appreciated.

Thank you!