在 AWS Cognito 中，建议不要从浏览器调用 /oauth2/token。为什么？

Question

我目前正在开发一个新项目，并使用 AWS Cognito 来处理身份验证方面的事情。

我们目前正在使用 oauth2 的授权代码流程。

团队中的不同开发人员对 AWS Cognito 文档的一部分有不同的解释，即这一条款：

/oauth2/token

端点仅支持

HTTPS POST

。您的应用程序使 直接向此端点发出请求，而不是通过用户的浏览器。

^ 来自 AWS Cognito - 令牌端点文档

我的问题是：为什么不应该从浏览器调用

/oauth2/token

端点？我假设他们不希望从浏览器中调用它是有原因的，但我正在努力解决“为什么”。 提前致谢。

Answer 1

/oauth2/token

端点支持

授权代码

（授权代码授予流程）和客户端机密（客户端凭证流程）。

grant_type

必须是 authorization_code
或

refresh_token

或

client_credentials

。

对于授权代码 (

/oauth2/authorize

)，它是用户到服务的身份验证，并且以交互方式进行。身份验证服务器将通过

HTTP 302

重定向来重定向客户端，从而返回授权码。然后，客户端（例如具有 PKCE 质询的 SPA）或后端本身可以使用授权代码来请求访问令牌 (

/oauth2/token

)，从而允许对受资源服务器保护的用户资源进行委派访问。对于客户端机密 (

/oauth2/token

)，它是服务到服务的身份验证，并且始终以非交互方式在后端 (

机密客户端

) 上进行，因为浏览器不适合保护机密 (公共客户端）。示例架构是“前端后端 (BFF) 代理”或“令牌中介后端”。 AWS Amplify 库和 Microsoft MSAL 都支持 SPA，后者使用 PCKE 启动授权代码授予流程并将令牌存储在客户端（浏览器）中。这被认为是安全的，并被网络应用程序广泛使用。 因此，以下引用仅在客户凭证的情况下才有意义，但也许一些专家更了解：

/oauth2/token

端点仅支持HTTPS POST。您的应用程序使 直接向此端点发出请求，而不是通过用户的浏览器。

XSS 威胁

Answer 2

Philippe De Rycks 的视频

中详细阐述了威胁。

更强的饼干

同时，在过去几年中，由于

RFC6265bis

对 cookie 的增强，浏览器仅 HTTP cookie 变得更加强大。特别是，SameSite=strict 设置可以防止跨站点请求伪造，这曾经是 cookie 的主要问题。

WEB OAUTH 最佳实践

因此，大多数热心浏览器安全的人所遵循的建议是来自

OAuth for Browser Based Apps

的Backend for Frontend方法。这解决的问题是减少 XSS 漏洞的影响。

网页架构

然而，对于想要构建 JavaScript 应用程序的组织来说，这是一个尴尬的要求，因为它需要一个额外的后端组件来发出 cookie。可以从架构的 Web 端或使用实用程序 API 发出 cookie。无论哪种方式，都会增加复杂性。

示例实现

出于兴趣，我的

初始 SPA 示例

从浏览器调用 Cognito 令牌端点，而我的最终 SPA 示例则通过发出 cookie 的实用程序 API 来执行此操作。这两种方法都是可行的，并且您可以从开发人员 PC 上运行它们，作为设计您自己的解决方案的一部分。