New Livestream: How Banks Protect Their Apps with FAPI 2.0.

Register Now!
Start for Free

The Backend for Frontend Pattern Is Now Official IETF Guidance: RFC 10017 Published

Joe DeCock
Two blue circles
Joe DeCock follows the OAuth working group, the OpenID Foundation, and the IETF and writes up what matters for working developers. Follow Joe on LinkedIn to catch his commentary as these standards evolve, and subscribe to the Duende newsletter using the form at the bottom of this page for implementation guidance, security updates, and deep dives delivered to your inbox.

If you've been following the identity standards world (or reading this blog), you know that the OAuth 2.0 for Browser-Based Applications specification has been in draft form for years. I mentioned it in my summer standards recap when it was finally submitted to the IESG for publication. It was one of those documents that everyone referenced, everyone agreed with, but that had been stuck behind various dependencies for a long time.

Well, it's done. The specification has been published as RFC 10017, formally designated as BCP 212.

What Is RFC 10017?

RFC 10017 is the IETF's Best Current Practice document for building browser-based applications (SPAs, JavaScript frontends, anything running in the browser) that use OAuth 2.0. It was authored by Aaron Parecki, Philippe De Ryck (who you may recognize from his guest appearance on our YouTube channel), and David Waite. The document details the threats, attack consequences, security considerations, and architectural patterns that developers need to understand when building these kinds of applications.

The core recommendation: pair your browser-based application with a server-side component, a Backend for Frontend (BFF), that acts as a confidential OAuth client, manages tokens server-side, and proxies API requests on behalf of the frontend.

If that sounds familiar, it should. We at Duende have been saying exactly this for years and building the tooling to make it practical.

From Draft to RFC: Why Does the Distinction Matter?

You might be thinking: "We've been following this guidance already. What changes?" Fair question. The core advice (use a BFF, don't expose tokens to JavaScript, don't use the Implicit grant) has been stable for a long time. We wrote about it when we released BFF v3 in 2025, and again when we explained why now is an excellent time to adopt BFF.

But the difference between a draft and an RFC is meaningful in ways that go beyond the technical content:

  1. IETF consensus. RFC 10017 represents the consensus of the IETF community. It has undergone public review and been approved by the Internet Engineering Steering Group (IESG). This isn't one person's opinion or a vendor recommendation. It's the collective judgment of the internet standards community.
  2. Compliance and governance. In regulated industries, pointing to an Internet Draft carries less weight than pointing to a published BCP. Security auditors, compliance teams, and risk officers understand RFCs. When your security architecture document says "we follow BCP 212," that means something concrete and verifiable.
  3. Stability. Internet Drafts change over time as the authors work to reach consensus. It's sometimes necessary to significantly rework a specification before it can be published, and it's not uncommon for drafts to never achieve enough adoption or consensus to be published. In contrast, RFC 10017 is a permanent, citable reference. The guidance is now fixed (barring future errata), and the security community can build on it with confidence.

What Does RFC 10017 Recommend?

RFC 10017 describes three architectural patterns for browser-based OAuth applications, presented in decreasing order of security:

1. Backend for Frontend (BFF): the recommended approach

The BFF acts as a confidential OAuth client. It handles the Authorization Code flow with PKCE, manages access and refresh tokens server-side, and maintains a cookie-based session with the browser. The frontend never sees a token. API requests go through the BFF, which attaches the appropriate access token before forwarding to resource servers.

This is the pattern we implement in Duende BFF.

2. Token-Mediating Backend

Similar to the BFF in that a backend handles OAuth responsibilities, but the frontend calls resource servers directly using access tokens obtained from the backend. This exposes tokens to JavaScript, which is less secure than the full BFF pattern.

3. Browser-Based OAuth Client

The frontend handles everything: authorization flows, token storage, API calls. This is the least secure option, and the RFC is very clear about the risks. Malicious JavaScript running in the same origin has the same privileges as your legitimate application code. It can steal tokens, run silent authorization flows in hidden iframes, or simply proxy requests through the user's browser. If you want to see some of these attacks in action, Erwin van der Valk demonstrated them in a livestream on our YouTube channel.

How Can Malicious JavaScript Attack Your OAuth Client?

One of the most valuable sections of RFC 10017 is its analysis of what malicious JavaScript can actually do to a browser-based OAuth client. The RFC walks through four attack scenarios:

  • Single-execution token theft: the attacker grabs tokens and exfiltrates them. The obvious one.
  • Persistent token theft: the attacker continuously harvests tokens, defeating short lifetimes and refresh token rotation.
  • Acquisition of new tokens: the attacker runs a silent Authorization Code flow in a hidden iframe, obtaining a completely fresh, independent set of tokens. This is the one that catches people off guard. Even DPoP doesn't help here, because the attacker uses their own key pair.
  • Proxying requests: the attacker sends requests to resource servers directly from within the compromised application. No token theft needed.

The BFF pattern mitigates most of these. Since tokens never reach the browser, there's nothing to steal. Since the BFF is a confidential client, an attacker can't run a new flow from the browser. The one attack that remains is proxying requests through the user's session, but that's the same risk that exists with any cookie-based web application, and it's well understood.

Should You Adopt the BFF Pattern Now?

If you're already using the BFF pattern, whether with Duende BFF or another implementation, you're in great shape. You've been following the best current practice before it was officially the Best Current Practice.

If you're not, the publication of RFC 10017 is a good reason to revisit your SPA security posture. We've written extensively about why this pattern matters and how to get started:

The RFC lays out the risks clearly, the pattern isn't hard to adopt, and we have the tooling and samples to get you there.

Read the RFC

The full text of RFC 10017 is available at https://www.rfc-editor.org/info/rfc10017. It's well written and worth reading in full, especially the threat analysis sections and the detailed BFF implementation guidance including cookie security requirements and CSRF protections.

If you have questions about implementing the BFF pattern or want to discuss how RFC 10017 applies to your architecture, come find me on our Discord. I'm always excited to talk about identity standards, specs, and the security problems they solve.

Related Articles