Skip to main content
Agent Identity

IETF · August 2026

OAuth 2.0 for Browser-Based Applications

RFC 10017 (BCP 212)

A. Parecki, D. Waite, P. De Ryck

RFCStableAuthorizationAdjacentField guide

OAuth 2.0 for Browser-Based Applications (RFC 10017 (BCP 212)) is RFC, August 2026. Chat UIs that broker agent OAuth in the browser are browser-based OAuth clients. XSS in the chat page is equivalent to stealing the agent's tokens.

ShareLinkedInX

At a glance

Problem
Code running in a browser cannot hide a client secret or reliably hide tokens from XSS. The implicit flow is unsafe. This BCP describes threats and recommended architectures (BFF vs. browser-only with PKCE).
Identity / authn / authz
Authorization for public clients in the browser. Complements OIDC for SPAs.

Actors

  • Browser-based app
  • Optional BFF
  • Authorization server

01

The gap for agents

RFC 10017 (BCP 212, August 2026) is the SPA story: code in the browser cannot hide a client secret or reliably hide tokens from XSS. Chat UIs that broker agent OAuth in the browser are browser-based OAuth clients. XSS in the chat page is equivalent to stealing the agent's tokens.

OAuth 2.1 draft-17 (31 October 2026) includes this text and cites RFC 10017. The RFC itself is the stable citation.

02

Actors and trust boundaries

The browser is hostile: XSS, malicious extensions, referrers. A Backend-for-Frontend that holds tokens in HTTP-only cookies moves the trust boundary to your server. Browser-only + PKCE keeps tokens in memory at best; localStorage is a gift to XSS.

03

Mechanics

Authorization code + PKCE. Prefer BFF. If tokens must live in the browser, keep them in memory. Implicit is forbidden. CORS must be set on token and other AS endpoints the SPA calls; not on the authorization endpoint (that is a redirect).

04

Step-by-step flows

Flow 1

BFF in front of a chat UI

  1. 1

    Browser talks only to your BFF with session cookies.

  2. 2

    BFF performs authorization code + PKCE as a confidential client.

  3. 3

    BFF calls MCP/SaaS APIs with the access token. The model never sees the token.

This is the architecture that makes prompt injection unable to exfiltrate the Bearer token — it never entered the browser or the prompt.

05

Identity vs authentication vs authorization

Authorization for public clients in the browser. Complements OIDC for SPAs. Does not define agent identity.

06

How it composes

  • OAuth 2.1

    Input document; 2.1 has not finished copying the normative text as of -16.

  • PKCE

    Required for the browser-only pattern.

  • OAuth Security BCP

    Same threat family: XSS, leakage, mix-up.

  • MCP authorization

    If the MCP client is a browser app, this BCP applies to how it holds tokens.

07

What bites agent implementers

  • Tokens in localStorage

    XSS reads them. Memory-only or BFF.

  • CORS on authorize

    FAPI and this BCP want redirects, not XHR, to the authorization endpoint.

08

Stability — what you can ship

RFC 10017 (BCP 212), August 2026, A. Parecki, D. Waite, P. De Ryck. Newly stable RFC. https://www.rfc-editor.org/rfc/rfc10017.html

Implementer notes

RFC 10017 published in August 2026. OAuth 2.1 draft-17 (31 October 2026) copies its normative browser-app requirements into the 2.1 draft and cites the RFC rather than draft-ietf-oauth-browser-based-apps-27. Cite the RFC for the BCP; cite draft-17 only for the consolidated framework.

Related

Primary sources