单页登录（SSO）单页应用程序（SPA）解决方案/架构

Question

我一直在研究SPA的SSO解决方案。有很多解决方案有细微差别，而我也发现并不是每个人都对SSO有相同的理解，并且没有很多已建立的SSO SSO模式。因此，我不是要求详细的设计/架构，而只是试着看看这个主题是否有任何常见的做法。

我对SSO意味着什么？

1. 我们正在开发一些新的SPA（也可能是移动和平板电脑应用），它们将部署在不同的服务器中，并具有不同的域。
2. 我们还有一个中央IdP（authServer），其中将存储所有用户标识。
3. 登入 SPA1 后，点击一个按钮，即 SPA2 （或 SPA3 ， SPA4 ，可能），我不必输入用户凭据，将自动登录。

SPA有什么区别？ （与常规网络应用程序相反）

我已经看过一些解决方案，甚至像SAML这样的旧解决方案（只是想了解一下SSO ......）。我当前的候选人是OpenId Connect，但后来我意识到SPA的区别，如果我的理解是正确的：与常规网络应用程序不同，SPA通常没有（或我们尝试不拥有）后端服务器。 SPA所拥有的只是一个服务器，提供静态页面以及脚本，样式表和图像。

现在出现了问题：

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

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

我的问题：

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

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

还有其他解决方案（框架，协议等）我应该知道但还没有探索过吗？

Answer 1

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

"OAuth 2.0 for Browser-Based Apps"-Draft 详细描述了您当前应该用来以安全方式为 SPA 实施 OAuth/OpenID Connect 的步骤。在 Sec. 4, "Overview" 中总结了当前的最佳做法：

<块引用>

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

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

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

<块引用>

基于浏览器的应用程序：

• 必须将 OAuth 2.0 授权代码流与 PKCE 一起使用 获取访问令牌时的扩展

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

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

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

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

Answer 2

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