Native applications

Native applications use a public NATIVE client, Authorization Code with S256 PKCE and an exact registered redirect URI. The OAuth token endpoint remains the only token issuer.

Choose the user experience

Hosted AppAuth login is the default integration. It keeps registration, password recovery, upstream providers, MFA and consent inside Identity. Use the mobile AppAuth tutorial for the complete flow.

The first-party native adapter is an explicit alternative for products that must collect credentials in native UI. The client must have nativeAuthenticationEnabled: true.

Flow

For hosted login, AppAuth discovers the issuer, opens /oauth2/authorize in the system browser and exchanges the callback code using the verifier it generated.

For native credential UI:

1. Create an interaction at {issuer}/oauth2/native/interactions with the client, callback, requested scopes, PKCE challenge, state and OIDC nonce.
2. Complete one supported authentication method against that interaction: password, email code or a configured upstream identity.
3. Complete TOTP or recovery-code verification when the response requires MFA.
4. Validate the returned issuer, state and callback.
5. Exchange the one-use authorization code at {issuer}/oauth2/token with the PKCE verifier.

The client must be explicitly enabled for native authentication. Interactive account selection, consent and unsupported prompts return browser_required; continue the same live interaction through the browser.

Credential management

Native registration and password recovery use separate one-use grants. They change credentials but do not create a login session or return OAuth tokens. Authenticate again after completion.

Social identity

Google, Apple and other native ID tokens are accepted only for configured provider audiences and authorized parties. An unlinked upstream identity never silently takes over an existing email account. An occupied email requires explicit account linking.