时间戳

首页 > 解决方案 > 客户端机密是否是在授权代码流中刷新 SPA 访问令牌的安全方法？

security - 客户端机密是否是在授权代码流中刷新 SPA 访问令牌的安全方法？

问题描述

在MSDN的文章中，它说需要执行以下请求才能使用 Web 应用程序的刷新令牌获取新的访问令牌。

POST /.../v2.0/token
内容类型：application/x-www-form-urlencoded

?client_id=...
&scope=wide_and_proud
&refresh_token=OAAABAAAAiL9Kn2Z27UubvWFP...
&grant_type=refresh_token
&client_secret=hakuna_matata

这意味着我们需要将客户端的秘密分发给前端应用程序，这对我来说打开了一个巨大的安全漏洞。我想说的是，我们永远不应该向我们的 SPA 提供有关客户秘密的信息。

我已经用谷歌搜索了几天，所有资源都以某种方式指向我们确实提供客户秘密的案例。但是，我无法摆脱在使用授权代码流进行 SPA 身份验证的情况下不应该应用的感觉。但是，我没有看到专门讨论组合的文档：“spa refresh token authorization code flow”。

标签： securityauthorizationsingle-page-applicationrefresh-token

解决方案

SPA 不应该使用客户端密码是对的。它还应该避免使用刷新令牌。问题是 SPA 无法安全地存储这些信息。

PKCE

SPA 是一个公共客户端，可以使用一次性运行时密码而不是客户端密码字段。有关详细信息，请参阅此代码交换证明密钥摘要。这将解决最初的问题。

令牌处理程序模式

如果您想更进一步，还有一个更广泛的问题是 SPA 需要一个服务器组件 (API) 来管理其机密和令牌。然后 SPA 可以发出这样的请求，API 可以处理敏感数据：

POST /login/end { url: location.href }

如果这是以 API 驱动的方式完成的，它也非常适合 SPA 架构的目标，尽管它确实添加了更多移动部分。有关更多信息，请参阅这些资源：

另请注意，这是一种通用设计模式。它将与 Microsoft 和任何其他授权服务器一起使用。

令牌处理程序第一步

您可以从这些步骤开始，这也将刷新令牌排除在 SPA 之外：

  • SPA 在 /login/start 调用 API 以获取重定向 URI
  • API 使用状态 + PKCE 参数设置临时 cookie
  • SPA 重定向并接收响应
  • SPA 再次调用 API，在 /login/end
  • 然后 API 将客户端密码提供给授权服务器
  • API 将刷新令牌存储在安全 cookie 中
  • API 将短期访问令牌返回给 SPA

推荐阅读