Implication: Teams should decide whether browser-held tokens are acceptable or whether a BFF should retain them server-side.
Watch condition: Watch whether browser-app frameworks and identity providers make PKCE and BFF architectures straightforward defaults.
Thesis
Browser-based OAuth security depends on treating the browser as an exposed public-client environment, not as a place to keep confidential credentials.
Observed facts
The OAuth.net page says RFC 10017 covers security requirements and best practices for OAuth 2.0 in applications whose code runs entirely in the browser.
1The page says browser-based apps cannot store a client secret and that code, tokens, and storage are visible to JavaScript on the page, including third-party scripts.
1
Mechanism
Because browser code and storage are exposed to page JavaScript, the guide recommends Authorization Code with PKCE and says not to use the Implicit flow. It recommends tokens in memory rather than localStorage, or a Backend-for-Frontend that holds tokens server-side and communicates via HttpOnly cookies.
Why now
RFC 10017 makes the browser-specific threat model and corresponding implementation choices explicit for teams building SPAs.
Implications
Teams should decide whether browser-held tokens are acceptable or whether a BFF should retain them server-side.
Evidence boundary
The supplied source excerpt reports the guidance and rationale; it does not establish adoption rates, comparative security outcomes, or implementation costs.
Watch conditions
Watch whether browser-app frameworks and identity providers make PKCE and BFF architectures straightforward defaults.