添加BFF确实改变了使用令牌的安全性。BFF是一个保密的客户端，因此它可以使整个解决方案更加安全，这是肯定的，但这不是使用BFF的唯一原因。主要的好处之一是使令牌远离浏览器。您不希望令牌被Javascript访问，这就是为什么要依赖基于Cookie的会话来保护您免受想要窃取令牌的XSS攻击的原因，使用会话会使您容易受到CSRF攻击和会话依赖攻击。骑马应该比缓解XSS要容易一些，因为您可能会由于第三方库的依赖性而容易受到XSS的攻击。
例如，如果是BFF：从cookie中窃取会话-〉向BFF发出请求-〉访问用户数据。2如果没有BFF：从cookie中窃取AT/RT-〉向API发出请求-〉访问用户数据。我仍然不明白这怎么会更安全，我很抱歉不理解它。
你不用道歉！你能理解这点很好。
你的例子的问题在于：假设没有BFF，但AT/RT保存在cookie中。如果使用cookie，则意味着在SPA和API之间有某种后端组件。否则，您必须在浏览器中处理令牌（JS可读）。因此，您应该考虑的区别是-我使用HTTP吗-只有cookie才能调用我的API，还是需要令牌并在JS中设置Authorization头？对于前一种情况，cookie中是否有会话ID或实际的AT并不重要。重要的是JS无法读取cookie的内容。
另一个问题是，窃取会话比窃取JS中的令牌更难。要想从cookie中窃取数据，你需要一个浏览器中间人攻击。如果JS可以获得令牌，那么你只需要一个XSS攻击就可以窃取它们。
正如我提到的，使用cookie会使您面临CSRF和会话骑乘攻击，但它们的影响是有限的：

• 攻击者只能在用户打开会话时执行攻击。一旦用户关闭浏览器，就不能再窃取数据（然而，当攻击者窃取令牌时，只要令牌有效，他们就可以读取数据）
• 攻击者只能执行用户从前端可以执行的相同操作。对于被盗的AT也应该是这种情况，但实际上，访问令牌通常具有太广泛的权限，并且您可以使用令牌调用一些API，而这些API通常无法从UI访问。

在Curity，我们花了一些时间对此进行了研究，您可以查看我们撰写的白皮书，了解SPA的安全性以及不同方法的优缺点：https://curity.io/resources/documents/single-page-application-security-whitepaper

BFF被认为是更安全的，不是因为***使用***访问令牌时使用cookie，而是因为***获得***令牌的方式更安全。SPA根据定义不能（在浏览器中）保守秘密，因此必须使用涉及公共客户端的流。BFF允许机密客户端，因为客户端秘密被保存在后端。
在公共客户端使用PKCE确实可以保证请求和接收令牌的是同一个实体，但它对该客户端的真实性几乎没有保证。