The Backend for Frontend Pattern Is Now Official IETF Guidance: RFC 10017 Published 后端即前端（BFF）模式现已成为 IETF 官方指南：RFC 10017 正式发布

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. 如果您一直关注身份认证标准领域（或阅读本博客），您会知道《基于浏览器的应用程序 OAuth 2.0 规范》（OAuth 2.0 for Browser-Based Applications）多年来一直处于草案阶段。我在夏季标准回顾中曾提到，该规范最终已提交至 IESG 进行发布。这曾是一份人人都引用、人人都赞同，却长期受制于各种依赖关系而无法发布的文档。

Well, it's done. The specification has been published as RFC 10017, formally designated as BCP 212. 现在，它完成了。该规范已作为 RFC 10017 发布，并正式被指定为 BCP 212。

What Is RFC 10017? 什么是 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. RFC 10017 是 IETF 为构建使用 OAuth 2.0 的浏览器端应用程序（如 SPA、JavaScript 前端以及任何在浏览器中运行的应用）所制定的“当前最佳实践”（Best Current Practice）文档。该文档由 Aaron Parecki、Philippe De Ryck（您可能在我们的 YouTube 频道嘉宾访谈中见过他）和 David Waite 共同撰写。文档详细阐述了开发者在构建此类应用时需要了解的威胁、攻击后果、安全考量及架构模式。

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. 其核心建议是：将浏览器端应用程序与服务器端组件——即“后端即前端”（BFF）配对。BFF 作为机密 OAuth 客户端，负责在服务器端管理令牌，并代表前端代理 API 请求。

If that sounds familiar, it should. We at Duende have been saying exactly this for years and building the tooling to make it practical. 如果这听起来很熟悉，那很正常。我们 Duende 多年来一直倡导这一理念，并致力于构建使其切实可行的工具。

From Draft to RFC: Why Does the Distinction Matter? 从草案到 RFC：这种区别为何重要？

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. 您可能会想：“我们已经在遵循这些指南了。有什么变化吗？”这是一个好问题。核心建议（使用 BFF、不要向 JavaScript 暴露令牌、不要使用隐式授权模式）长期以来一直保持稳定。我们在 2025 年发布 BFF v3 时曾对此进行过撰文，在解释为何现在是采用 BFF 的绝佳时机时也再次强调过。

But the difference between a draft and an RFC is meaningful in ways that go beyond the technical content: 但草案与 RFC 之间的区别，其意义远超技术内容本身：

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. IETF 共识。RFC 10017 代表了 IETF 社区的共识。它经过了公众评审，并已获得互联网工程指导小组（IESG）的批准。这不再是个人的观点或厂商的建议，而是互联网标准社区的共同判断。
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. 合规与治理。在受监管的行业中，引用“互联网草案”的效力远不及引用已发布的 BCP。安全审计员、合规团队和风险官都认可 RFC。当您的安全架构文档中写明“我们遵循 BCP 212”时，这意味着具体且可验证的承诺。
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. 稳定性。互联网草案在作者努力达成共识的过程中会不断变化。有时在发布前需要对规范进行重大重构，而且草案因无法获得足够的采用或共识而最终未能发布的情况也并不罕见。相比之下，RFC 10017 是一个永久的、可引用的参考标准。该指南现已固定（除非未来有勘误），安全社区可以放心地以此为基础进行开发。

What Does RFC 10017 Recommend? RFC 10017 推荐了什么？

RFC 10017 describes three architectural patterns for browser-based OAuth applications, presented in decreasing order of security: RFC 10017 描述了三种针对浏览器端 OAuth 应用的架构模式，按安全性从高到低排列：

1. Backend for Frontend (BFF): the recommended approach 1. 后端即前端（BFF）：推荐方案

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. BFF 作为机密 OAuth 客户端运行。它处理带有 PKCE 的授权码流程，在服务器端管理访问令牌和刷新令牌，并维护与浏览器之间的基于 Cookie 的会话。前端永远不会接触到令牌。API 请求通过 BFF 进行，BFF 会在转发给资源服务器之前附加上适当的访问令牌。

This is the pattern we implement in Duende BFF. 这正是我们在 Duende BFF 中实现的模式。

2. Token-Mediating Backend 2. 令牌中介后端

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. 与 BFF 类似，后端处理 OAuth 相关职责，但前端使用从后端获得的访问令牌直接调用资源服务器。这会将令牌暴露给 JavaScript，其安全性低于完整的 BFF 模式。

3. Browser-Based OAuth Client 3. 浏览器端 OAuth 客户端

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. 前端处理所有事务：授权流程、令牌存储、API 调用。这是安全性最低的选项，RFC 对其中的风险表述得非常清晰。在同一源下运行的恶意 JavaScript 拥有与您的合法应用代码相同的权限。它可以窃取令牌、在隐藏的 iframe 中运行静默授权流程，或者仅仅是通过用户的浏览器代理请求。如果您想了解这些攻击的实际操作，Erwin van der Valk 曾在我们 YouTube 频道的直播中进行过演示。

How Can Malicious JavaScript Attack Your OAuth Client? 恶意 JavaScript 如何攻击您的 OAuth 客户端？

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: RFC 10017 最有价值的部分之一是对恶意 JavaScript 实际上能对浏览器端 OAuth 客户端造成何种影响的分析。RFC 列举了四种攻击场景：

• 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. 获取新令牌：攻击者在隐藏的 iframe 中运行静默授权码流程，从而获得一组全新的、独立的令牌。这是最让人防不胜防的一种。即使是 DPoP 在此也无能为力，因为攻击者使用的是他们自己的密钥对。
• 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. BFF 模式缓解了上述大部分攻击。由于令牌从未到达浏览器，因此无物可窃。由于 BFF 是机密客户端，攻击者无法从浏览器发起新的流程。唯一剩下的攻击方式是通过用户的会话代理请求，但这与任何基于 Cookie 的 Web 应用所面临的风险相同，且已被充分理解。

Should You Adopt the BFF Pattern Now? 您现在应该采用 BFF 模式吗？

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. 如果您已经在通过 Duende BFF 或其他实现方式使用 BFF 模式，那么您的状态非常好。在它正式成为“当前最佳实践”之前，您就已经在遵循这一最佳实践了。

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: 如果您尚未采用，RFC 10017 的发布是一个重新审视您 SPA 安全状况的好理由。我们已经撰写了大量文章，阐述了为什么这种模式很重要以及如何开始实施：

• Why Now is an Excellent Time for Backend for Frontend 为什么现在是采用“后端即前端”的最佳时机
• Secure a Vue app with OpenID Connect and the BFF pattern 使用 OpenID Connect 和 BFF 模式保护 Vue 应用
• Samples for React, Angular, Vue, Blazor, and vanilla JavaScript 针对 React、Angular、Vue、Blazor 和原生 JavaScript 的示例
• Duende BFF documentation Duende BFF 文档

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. RFC 明确列出了风险，该模式并不难采用，而且我们拥有帮助您完成实施的工具和示例。

Read the RFC 阅读 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. RFC 10017 的全文可在 https://www.rfc-editor.org/info/rfc10017 获取。它撰写得非常出色，值得通读，特别是威胁分析部分以及包含 Cookie 安全要求和 CSRF 防护在内的详细 BFF 实施指南。

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. 如果您对实施 BFF 模式有疑问，或者想讨论 RFC 10017 如何应用于您的架构，欢迎在我们的 Discord 上找我。我总是很乐意讨论身份认证标准、规范以及它们所解决的安全问题。