4

一段时间以来，我一直在研究 SPA 的 SSO 解决方案。有很多细微差别的解决方案，但我也发现并不是每个人都对 SSO 有相同的理解，而且针对 SPA 的 SSO 的既定模式也并不多。因此，我不是要求详细的设计/架构，而只是尝试看看在这个主题上是否有任何常见的做法。

我对 SSO 意味着什么？

  1. 我们正在开发一些新的 SPA（也可能是移动和平板电脑应用程序），它们将部署在不同的服务器上并具有不同的域。
  2. 我们还有一个中央 IdP (authServer) 将存储所有用户身份。
  3. 一旦我登录SPA1并单击将我带到SPA2（或SPA3，SPA4，可能）的按钮，我不必输入用户凭据，并且会自动登录。

SPA有什么区别？（相对于常规的网络应用程序）

我查看了一些解决方案，甚至是像 SAML 这样的旧解决方案（只是想了解 SSO ..）。我目前的候选人是OpenId Connect，但后来我意识到 SPA 的不同之处，如果我的理解是正确的：与常规 Web 应用程序不同，SPA 通常没有（或者我们尽量没有）后端服务器。SPA 所拥有的只是一个服务于静态页面以及脚本、样式表和图像的服务器。

现在问题来了：

OpenId Connect基于OAuth2 授权代码授权类型，这意味着：

  1. 如果我想让每个 SPA 工作，我需要一个类似后端代理的模块。
  2. 我使用不同的解决方案来执行客户端 SSO，例如auth0 提供的一个
  3. 我还没有找到任何其他解决方案/示例

我的问题：

对于上述第 1 点，我的理解是否正确？不要让 SPA 像普通的 web 应用程序那样拥有后端代码会更好吗？

对于上述第 2 点，这听起来像是一个解决方案，但这与OAuth2 隐式授权类型有何本质不同？

而且，还有其他我应该知道但尚未探索的解决方案（框架、协议等）吗？

4

2 回答 2

2

如今，代码流与跨域资源共享 ( CORS ) 和代码交换证明密钥 ( PKCE ) 相结合，也可用于单页应用程序。

“基于浏览器的应用程序的 OAuth 2.0”草案详细描述了您应该使用的当前步骤，以以安全的方式为 SPA 实施 OAuth/OpenID Connect。在秒。4、《概述》目前的最佳实践总结：

近年来，跨域资源共享 (CORS) 的广泛采用，允许同源策略例外，允许基于浏览器的应用程序使用 OAuth 2.0 授权码流并发出 POST 请求以交换授权码令牌端点的访问令牌。在这个流程中，访问令牌永远不会暴露在不太安全的前端通道中。此外，将 PKCE 添加到流程中可确保即使授权代码被截获，攻击者也无法使用它。

出于这个原因，以及从其他经验教训中，目前基于浏览器的应用程序的最佳实践是使用带有 PKCE 的 OAuth 2.0 授权代码流。

该草案恢复了以下关键点，在为 SPA（或其他公共客户端）实施 OAuth/OpenID 时应考虑：

基于浏览器的应用程序：

  • 获取访问令牌时必须使用带有 PKCE 扩展的 OAuth 2.0 授权代码流

  • 必须通过以下任一方式保护自己免受 CSRF 攻击：

    • 确保授权服务器支持 PKCE，或

    • 通过使用 OAuth 2.0 “state” 参数或 OpenID Connect “nonce” 参数来携带一次性使用 CSRF 令牌

  • 必须注册一个或多个重定向 URI，并且在授权请求中只使用准确注册的重定向 URI

于 2021-01-16T13:30:18.400 回答
1

除了使用授权码授权的基本客户端配置文件之外，OpenID Connect 还具有一个基于 OAuth 2.0 的隐式授权的隐式客户端配置文件。此配置文件允许将令牌直接传递给浏览器内/Javascript 客户端，而无需涉及后端。

于 2015-10-24T06:45:02.040 回答