From 69b805dd33c5049ba59bc7ebd8c57c3e848251b5 Mon Sep 17 00:00:00 2001 From: Joost de Valk Date: Fri, 11 Sep 2026 08:08:56 +0200 Subject: [PATCH 1/2] add(considered): RFC 10017 OAuth for browser apps has nothing at the origin BCP 212 (published 2026-08-21) ranks BFF / token-mediating / browser-only architectures for SPAs using OAuth. Recorded as out-of-scope: where the tokens live is not observable from outside, and the origin-visible parts (cookie attributes, nonce/hash CSP) are already specced. Notes the __Host-Http- prefix as a possible later addition to cookie-attributes. Co-Authored-By: Claude Opus 5 (1M context) --- .../considered/oauth-browser-based-apps.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 src/content/considered/oauth-browser-based-apps.md diff --git a/src/content/considered/oauth-browser-based-apps.md b/src/content/considered/oauth-browser-based-apps.md new file mode 100644 index 00000000..4449092d --- /dev/null +++ b/src/content/considered/oauth-browser-based-apps.md @@ -0,0 +1,19 @@ +--- +title: "OAuth 2.0 for Browser-Based Applications (RFC 10017 / BCP 212)" +date: "2026-09-11" +reason: out-of-scope +revisit: "If the BCP's advice grows an artefact a site publishes — metadata declaring that its tokens are held server-side or sender-constrained, say — that artefact would be the topic. Separately, the `__Host-Http-` cookie prefix it recommends earns a line on the cookie attributes page once browsers are confirmed to enforce it." +sources: + - title: "RFC 10017 — OAuth 2.0 for Browser-Based Applications" + url: "https://www.rfc-editor.org/rfc/rfc10017.html" + publisher: "IETF" + - title: "RFC 9700 — Best Current Practice for OAuth 2.0 Security" + url: "https://www.rfc-editor.org/rfc/rfc9700" + publisher: "IETF" +--- + +RFC 10017, published in August 2026 as BCP 212, is the IETF's guidance for single-page applications that use OAuth. It ranks three architectures. In a backend-for-frontend (BFF), the server holds every token and the browser only ever sees a session cookie. A token-mediating backend obtains the tokens but hands access tokens to the browser. A purely browser-based client holds everything itself. The BCP strongly recommends the BFF for business applications, sensitive applications and anything handling personal data, and requires PKCE and rotating or sender-constrained refresh tokens whichever pattern is used. + +Its central question — where the tokens live — cannot be answered from outside a site. Nothing in a response tells an observer whether an access token sits in a server session or in JavaScript memory. The document is written for the people building the OAuth client, and they are the only ones who can check it. The parts that do surface at the origin are already covered here. The BFF's cookie must be `Secure` and `HttpOnly`, and should be `SameSite=Strict` ([cookie attributes](/spec/security/cookie-attributes/)). Injected script is to be stopped with a nonce- or hash-based policy ([Content Security Policy](/spec/security/content-security-policy/)). A site that meets those two pages has done the half of the BCP that anyone else can see; the rest is architecture. + +This is the line drawn for [cross-device flow security](/considered/#cross-device-flow-security): a sound best-practice document aimed at authentication engineers, with nothing of its own at the origin. One detail may still reach this spec by another route. For the BFF's cookie, the RFC recommends the `__Host-Http-` prefix, which marks a cookie as set over HTTP rather than by script. It is newer than the `__Host-` and `__Secure-` prefixes the cookie attributes page describes, and browser support for it has not yet been confirmed here. From 3d64fd2d91bfef957523542371500b97a3f151e3 Mon Sep 17 00:00:00 2001 From: Joost de Valk Date: Fri, 11 Sep 2026 19:02:26 +0200 Subject: [PATCH 2/2] Scope OAuth refresh-token requirements to public clients --- src/content/considered/oauth-browser-based-apps.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/considered/oauth-browser-based-apps.md b/src/content/considered/oauth-browser-based-apps.md index 4449092d..d93975aa 100644 --- a/src/content/considered/oauth-browser-based-apps.md +++ b/src/content/considered/oauth-browser-based-apps.md @@ -12,8 +12,8 @@ sources: publisher: "IETF" --- -RFC 10017, published in August 2026 as BCP 212, is the IETF's guidance for single-page applications that use OAuth. It ranks three architectures. In a backend-for-frontend (BFF), the server holds every token and the browser only ever sees a session cookie. A token-mediating backend obtains the tokens but hands access tokens to the browser. A purely browser-based client holds everything itself. The BCP strongly recommends the BFF for business applications, sensitive applications and anything handling personal data, and requires PKCE and rotating or sender-constrained refresh tokens whichever pattern is used. +RFC 10017, published in August 2026 as BCP 212, is the IETF's guidance for single-page applications that use OAuth. It ranks three architectures. A backend-for-frontend (BFF) keeps tokens out of application JavaScript; the browser authenticates to it with a session cookie. A token-mediating backend obtains the tokens but hands access tokens to the browser. A purely browser-based client holds everything itself. The BCP strongly recommends the BFF for business applications, sensitive applications and anything handling personal data. Public browser clients must use PKCE and, if issued refresh tokens, those tokens must be rotated or sender-constrained. The refresh-token requirement in [RFC 9700 §2.2.2](https://www.rfc-editor.org/rfc/rfc9700.html#section-2.2.2) applies to public clients; confidential backends authenticate when using their refresh tokens and are not universally required to rotate or sender-constrain them. -Its central question — where the tokens live — cannot be answered from outside a site. Nothing in a response tells an observer whether an access token sits in a server session or in JavaScript memory. The document is written for the people building the OAuth client, and they are the only ones who can check it. The parts that do surface at the origin are already covered here. The BFF's cookie must be `Secure` and `HttpOnly`, and should be `SameSite=Strict` ([cookie attributes](/spec/security/cookie-attributes/)). Injected script is to be stopped with a nonce- or hash-based policy ([Content Security Policy](/spec/security/content-security-policy/)). A site that meets those two pages has done the half of the BCP that anyone else can see; the rest is architecture. +Its central recommendations concern how the OAuth client obtains, stores and uses tokens. Assessing those choices requires inspecting the application's authentication flow and implementation; published origin metadata alone does not establish compliance. Some website-level controls are already covered here. The BFF's cookie must be `Secure` and `HttpOnly`, and should be `SameSite=Strict` ([cookie attributes](/spec/security/cookie-attributes/)). A nonce- or hash-based policy helps prevent injected script from executing ([Content Security Policy](/spec/security/content-security-policy/)). These are useful checks, but meeting them does not establish compliance with the whole BCP. This is the line drawn for [cross-device flow security](/considered/#cross-device-flow-security): a sound best-practice document aimed at authentication engineers, with nothing of its own at the origin. One detail may still reach this spec by another route. For the BFF's cookie, the RFC recommends the `__Host-Http-` prefix, which marks a cookie as set over HTTP rather than by script. It is newer than the `__Host-` and `__Secure-` prefixes the cookie attributes page describes, and browser support for it has not yet been confirmed here.