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, especially JavaScript clients and SPAs, where OAuth tokens, redirect flows, third-party scripts, browser storage, extensions, and automated browser agents share the same security boundary.

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

Snapshot

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, with the Datatracker listing it as an active Internet-Draft, intended status Best Current Practice, and latest revision dated 3 December 2025. The text itself is dated December 2025 and says it expires on 7 June 2026. 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, service workers, and possibly an AI browser agent all occupy the same security neighborhood.

The page is about OAuth authorization for browser-executed clients. It is not a general web-login guide, and it is not the same as OAuth for Native Apps, backend confidential-client OAuth, or OpenID Connect sign-in for a same-domain web application that merely uses OAuth machinery underneath identity login.

Current Context

As of June 25, 2026, the browser-based apps document is still a draft rather than a numbered RFC. The governance implication is simple: treat it as the current IETF working guidance for this application class, but anchor mandatory production controls in stable RFCs where possible. RFC 9700, published in January 2025 as Best Current Practice for OAuth 2.0 Security, is the stable baseline that the browser-based apps draft expands and restricts for the browser setting.

OAuth 2.1 is also still an Internet-Draft, not a final RFC. The March 2026 draft says it consolidates OAuth 2.0 with later security updates, but production documentation should continue to cite the specific RFCs and drafts that actually apply: RFC 6749, RFC 6750, RFC 7636, RFC 8252, RFC 9449, RFC 9700, RFC 9728, and the exact browser-based apps draft version.

The web platform side has also moved. Content Security Policy Level 3 was a W3C Working Draft in May 2026, and WHATWG HTML continues to define browser storage APIs such as sessionStorage and localStorage. Those sources do not become OAuth standards, but they define the execution and storage surfaces that OAuth browser clients rely on.

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 draft explicitly moves away from 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, browser history, referrers, or page-visible flows.

Browser-based OAuth clients should be treated as public clients unless they use a real backend component that can keep credentials confidential. A static secret shipped inside JavaScript is not proof of client identity, because users and attackers can inspect or copy the downloaded code.

Token handling is the center of the design. Access tokens should be narrow, audience-limited, short-lived, and protected from browser-visible logs and storage when possible. Refresh tokens in browser contexts require special care: RFC 9700 and the draft point toward refresh-token rotation or sender constraint where refresh tokens are issued to public clients.

Architecture Patterns

Backend for Frontend. A BFF is a server-side component that acts as a confidential OAuth client. It handles the authorization-code flow, stores access and refresh tokens server-side, maintains a cookie-based session with the browser, and proxies protected-resource requests. This avoids exposing OAuth tokens directly to frontend JavaScript, but it shifts risk to session-cookie security, CSRF controls, outbound proxy allowlists, and backend compromise.

Token-mediating backend. A token-mediating backend also handles OAuth responsibilities as a backend component, but the browser application may receive an access token and call resource servers directly. This can reduce long-term refresh-token exposure but still leaves direct access-token theft as a serious risk if malicious JavaScript runs in the application context.

Browser-only OAuth client. A browser-only client runs the OAuth client logic in frontend code. It is a public client, cannot keep client secrets, and has to manage tokens in browser storage or memory under the threat of XSS, malicious dependencies, compromised CDNs, browser extensions, and model-visible automation surfaces. It should use Authorization Code with PKCE and avoid long-lived browser-readable credentials.

Same-domain web application. The draft also notes that a frontend and API on a common domain may not need OAuth for frontend-to-backend calls. Such systems can use OpenID Connect or another sign-in mechanism for user authentication and maintain application session state without turning the browser frontend into an OAuth client for cross-party API authorization.

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, screenshot, memory, support bundle, 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.

Browser OAuth should not be treated as user approval for every action in the session. A token can authorize API access while the agent still needs step-specific policy checks, human confirmation for high-impact actions, and clear audit records linking the OAuth grant to the agent run.

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, issuer, PKCE method, refresh-token policy, token storage location, resource server audience, scopes, DPoP or other sender-constraint status, agent run identifier, user approval event, and revocation path. Logs should not store authorization codes, code verifiers, access tokens, refresh tokens, session cookies, private keys, or model-visible copies of secret material.

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

For high-value workflows, procurement and security review should prefer BFF-style designs unless the organization has a clear reason to expose tokens to browser code. If a browser-only client is accepted, the decision should document token lifetime, storage, refresh policy, CSP, dependency controls, XSS testing, extension exposure, and agent telemetry redaction.

Minimum Evidence Record

A governance-grade browser OAuth record should make the delegation path reviewable without preserving reusable secrets.

Failure Modes

Defense Pattern

Source Discipline

Claims about browser-based OAuth should name the architecture pattern: BFF, token-mediating backend, browser-only client, or same-domain web application. They should also distinguish browser-based apps from native apps, device authorization, backend confidential clients, OpenID Connect sign-in, and ordinary session-cookie authentication.

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 6750, RFC 7636, RFC 9449, RFC 9700, and RFC 9728 when making production policy. Cite W3C CSP and WHATWG HTML for browser execution and storage surfaces, not as OAuth authority.

For implementation claims, require evidence: redirect URI registration, authorization-server metadata, PKCE enforcement, token lifetimes, storage design, refresh-token behavior, CSP policy, script and dependency controls, DPoP or bearer-token status, resource indicators, resource-server audience validation, and redacted audit logs. "Uses OAuth" is not enough.

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