假设我有一个SPA，它的后端在同一个域上。如果我必须连接到外部OAuth提供商（比如Google），授权代码流（没有PKCE）是更安全的选择。这意味着：

• SPA向授权服务器请求code
• 然后，它将该code发送到后端
• 后端与AS交换code（和一个密钥），以获取令牌
• 后台与SPA设置Session Cookie保持用户登录状态

此流是最安全的，因为SPA永远不会看到单个令牌。它不使用它们。如果我必须使用访问令牌向API发出请求，SPA将向后端发出请求，后端将使用访问令牌获取资源。后端也负责使用刷新令牌。到目前为止一切顺利。
现在，如果后端在成功交换后（一旦它获得令牌），将令牌发送回浏览器呢？这样，客户端就可以自己访问API的端点。
从理论上讲，如果我没有弄错的话，这应该是可以避免的。将令牌返回给前端有点违背了授权代码授予的目的，您还不如使用授权代码w/ PKCE来直接在前端获取令牌，对吗？通过代码授权，是后端而不是SPA进行身份验证。
但我在想这就是Firebase所做的不是吗据我所知，Firebase使用授权码（没有PKCE），重定向到Firebase App的后端（__auth/handler），然后它仍然会将令牌给前端（id令牌，访问令牌，刷新令牌）。
我错过了什么吗？或者在授权码授予结束时将令牌交给前端可以吗？
PS.显然，在Firebase的情况下，后端实际上不会使用这些令牌，它依赖于在每个请求中发送的浏览器令牌。在我提到的例子中，后端存储了这些令牌，所以理论上我有两组令牌：后端通过代码交换接收的数据，以及发送到浏览器的数据（最初它们是相同的，但在第一次刷新后它们就不同了）。后端是否应该完全丢弃令牌并依赖于浏览器令牌？我认为应该是这样，因为如果启用了刷新令牌循环，后端在浏览器第一次刷新后将有一个无效的刷新令牌。这种情况快把我逼疯了我的观点是令牌应该保留在后端，但我试图弄清楚Firebase方法如何安全。