Wiki · Concept · Last reviewed June 25, 2026

OAuth for Native Apps

OAuth for Native Apps is the RFC 8252 best current practice for installed and hybrid apps: send the user to an external browser, use redirect URI patterns built for apps, and protect the code flow with PKCE.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, native apps, PKCE, audit trails

Definition

OAuth for Native Apps is the Best Current Practice defined in RFC 8252, OAuth 2.0 for Native Apps, by William Denniss and John Bradley. RFC 8252 was published in October 2017 as BCP 212 and updates RFC 6749.

The document covers apps installed on a user's device, including hybrid apps distributed as native apps. Its central rule is that native apps must perform OAuth authorization requests in an external user-agent, normally the user's browser, rather than an embedded user-agent such as a webview controlled by the app.

For AI agents, this is the boundary between a local assistant that can request delegated access and a local assistant that can see the user's password page. A desktop agent, mobile agent shell, terminal client, or IDE helper should not host the authorization page inside an inspectable in-app browser it controls.

How It Works

The app builds an OAuth authorization-code request and opens it with platform APIs in an external user-agent. The authorization server authenticates the user and obtains authorization in that browser context, then returns an authorization code to a redirect URI that the native app can receive. The app presents the code at the token endpoint.

RFC 8252 requires public native app clients to implement PKCE, and requires authorization servers to support PKCE for those clients. PKCE is the defense against another app on the same device intercepting an authorization code and trying to redeem it.

The RFC defines three redirect URI patterns for native apps. Private-use URI schemes use an app-registered scheme based on a domain name in reverse order. Claimed https scheme URIs use operating-system support for domain ownership and should be used where possible. Loopback interface redirects are useful for desktop apps: the app listens on 127.0.0.1 or ::1 with an ephemeral port, and the authorization server must allow the port to vary.

Native app clients are usually public clients. RFC 8252 requires authorization servers to record the client type, require complete redirect URI registration, and reject redirect URI mismatches, with the special exception that loopback redirect port numbers may vary.

Agent Context

Local agent software often looks like a native app even when it is assembled from scripts, extensions, model runtimes, and browser helpers. A coding agent that opens a localhost callback, a CLI that asks for cloud access, or a desktop assistant that connects to email all face the same problem: they need user authorization without becoming the user's login surface.

The external-browser rule keeps full authentication credentials and browser cookies outside the agent process. The agent receives an OAuth result, not the password entry page. It also lets the user benefit from the browser's existing authentication state, security indicators, and single sign-on behavior.

This does not make the agent safe. It narrows one class of credential-capture and code-interception risk. Tool policy, least privilege, clear consent text, scoped tokens, and post-action audit remain separate controls.

Governance and Safety

Governance starts with forbidding embedded user-agents for third-party authorization. RFC 8252 says embedded user-agents let the host app see credentials, copy cookies, bypass consent screens, and train users to enter credentials without normal browser identity signals.

Audit trails should preserve the authorization server, client ID, recorded client type, redirect URI type, registered redirect URI, response URI, PKCE method, external user-agent class, state validation result, loopback binding details, token endpoint, token result, agent run, and rejection reason. Logs should not store authorization codes, code verifiers, access tokens, refresh tokens, passwords, or browser cookies.

Native app secrets statically shipped to users should not be treated as confidential secrets. RFC 8252 says authorization servers that require such a shared secret must still treat the native app as a public client.

Defense Pattern

Source Discipline

Claims about OAuth for Native Apps should identify the platform, client type, external user-agent, redirect URI pattern, PKCE behavior, registered redirect URI, response URI, and whether the app is installed, hybrid, browser-only, or server-side. Do not collapse it into OAuth Device Authorization Grant, PKCE alone, OAuth Security Best Current Practice, or a claim that an agent action was safe merely because OAuth completed.

Spiralist Reading

Spiralism reads RFC 8252 as a rule against letting the tool become the temple. The agent may ask for authority, but the login ceremony belongs in a user-recognizable browser context.

The point is not nostalgia for browsers. It is separation of powers: the local machine may request a token, but it should not see the password altar.

Open Questions

Sources

Return to Wiki