Wiki · Concept · Last reviewed June 25, 2026

OAuth for Browser-Based Apps

OAuth for Browser-Based Apps is the IETF OAuth Working Group guidance for browser-executed applications, including SPAs, BFF patterns, token-mediating backends, Authorization Code with PKCE, and the special risks of tokens inside JavaScript execution contexts.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: AI agents, authorization, OAuth, browser apps, PKCE, token exposure

Definition

OAuth for Browser-Based Apps refers to the IETF OAuth Working Group draft OAuth 2.0 for Browser-Based Applications, by Aaron Parecki, Philippe De Ryck, and David Waite. The version used here is draft-ietf-oauth-browser-based-apps-26, published on 4 December 2025 with intended status Best Current Practice. Until an RFC number exists, policy should cite the draft version explicitly.

The draft defines a browser-based application as an application dynamically downloaded and executed in a web browser, usually JavaScript, and often called a single-page application or SPA. That matters because the OAuth client, the user interface, third-party scripts, browser storage, extensions, and possibly an AI browser agent all occupy the same security neighborhood.

How It Works

The draft says the modern best practice for browser-based OAuth is the Authorization Code grant type with PKCE. RFC 9700 also says public clients must use PKCE to prevent authorization code injection and misuse, authorization servers must support PKCE, and S256 is the method that does not expose the verifier in the authorization request.

The browser-based apps draft separates three main architecture patterns. In a Backend for Frontend (BFF), a server-side component becomes the OAuth client, manages access and refresh tokens behind a cookie-based session, and proxies protected-resource requests. In a token-mediating backend, a backend handles OAuth responsibilities but the browser application calls resource servers directly with an access token. In a browser-only OAuth client, the frontend handles tokens directly and therefore has to confront browser storage, token lifetime, refresh token handling, and malicious JavaScript more directly.

The same draft explicitly deprecates the old comfort around the implicit grant for this setting. Browser-based clients are told to obtain access tokens from the token endpoint through Authorization Code, not through a front-channel implicit response that leaves token material in places such as URL fragments, logs, history, or page-visible flows.

Agent Context

Agentic browsing makes this guidance more urgent. A human using a SPA can often distinguish a login redirect, a consent screen, a payment widget, and an application error. A browser agent may see the same page as text, screenshots, DOM nodes, tool calls, and credentials hidden behind browser state. OAuth completion then becomes an event inside a larger delegated workflow, not proof that the agent should take every downstream action.

For an agent that reads pages, clicks buttons, fills forms, or calls web APIs, the main question is whether token material ever enters a place the model, prompt, page script, extension, logging layer, or transcript can read. Browser OAuth is therefore also an AI Agent Identity issue: resource servers still need to know who acted, which user authorized the action, what scope was granted, and which automation policy governed the step.

Governance and Safety

The controlling risk is malicious or confused code in the browser execution context. The IETF draft analyzes token theft, persistent token access, acquisition of fresh tokens, proxying through the user's browser, and client hijacking. Those are web-security problems, but they become agent-governance problems when a model can continue a workflow after the page has changed authority state.

Governance should record the architecture pattern, client ID, redirect URI, authorization server, PKCE method, refresh-token policy, storage location, resource server audience, scopes, agent run identifier, user approval event, and revocation path. Logs should not store authorization codes, code verifiers, access tokens, refresh tokens, session cookies, or model-visible copies of secret material.

Controls such as Content Security Policy, origin isolation, sender-constrained tokens, refresh-token rotation, and short access-token lifetimes can reduce risk. They do not make malicious JavaScript harmless, and they do not turn a browser agent into an authorized principal by themselves.

Defense Pattern

Source Discipline

Claims about browser-based OAuth should name the architecture pattern: BFF, token-mediating backend, or browser-only client. They should also distinguish browser-based apps from native apps, device authorization, backend confidential clients, and OpenID Connect sign-in for a same-domain web application that does not use OAuth for cross-party API authorization.

Because draft-ietf-oauth-browser-based-apps-26 is still a draft source rather than a numbered RFC, cite the exact draft version and pair it with stable sources such as RFC 6749, RFC 7636, and RFC 9700 when making production policy.

Spiralist Reading

Spiralism reads browser OAuth as a ritual of delegated agency performed inside a crowded room. The user, page code, identity provider, resource server, browser extension, analytics script, security policy, and agent all stand near the same token boundary.

The practical ethic is simple: do not confuse a successful consent redirect with trustworthy action. A token is a narrow credential, not a blessing over the entire browser session.

Open Questions

Sources

Return to Wiki