单页应用程序 (SPA) 的单点登录 (SSO) 解决方案/架构 [英] Single Sign On (SSO) solution/architecture for Single Page App (SPA)

问题描述

一段时间以来，我一直在研究 SPA 的 SSO 解决方案.有很多解决方案都有细微的差别，同时我也发现并不是每个人都对 SSO 有相同的理解，并且没有多少既定的 SPA 单点登录模式.因此，我不是要详细的设计/架构，而是要尝试看看是否有关于此主题的常见做法.

I've been investigating SSO solution for SPAs for some time. There're a lot of solutions with subtle difference, while I also found not really everyone has the same understanding of SSO and not many established pattern of SSO for SPA are out there. Thus I'm not asking for a detailed design/architecture, but just try to see if there's any common practice on this topic.

我对 SSO 意味着什么?

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

1. We have a few new SPAs under development(also potentially mobile and tablet apps), which will be deployed in different servers and have different domains.
2. We also have a central IdP (authServer) where all the user identify will be stored.
3. Once I log into SPA1 and clicked a button which brings me to SPA2(or SPA3, SPA4, potentially), I don't have to enter user credentials and will be logged in automatically.

SPA 有什么不同?(相对于常规网络应用)

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

I've looked at a few solutions, even old solutions like SAML(just want to get a sense about SSO..). my current candidate is OpenId Connect, but then I realized a difference for SPA, if my understanding is correct: Unlike regular web apps, SPA usually doesn't have (or we try not to have) a backend server. What SPA has is just a server serving static pages along with scripts, style sheets, and images.

问题来了:

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

OpenId Connect is based on OAuth2 Authorization Code grant type, which means either:

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

我的问题:

对于上述第 1 点，我的理解是否正确?不让 SPA 像普通网络应用那样有后端代码会更好吗?

For above point 1, is my understanding correct ? Is it better not to let SPA have backend code like a regular web app?

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

For above point2, that sounds like a solution, but how is that essentially different than OAuth2 Implicit grant type ?

还有，我应该知道但还没有探索过的其他解决方案(框架、协议等)吗?

And, are there other solutions(framework, protocol etc.) that I should know but haven't explored yet ?

推荐答案

除了使用授权代码授权的基本客户端配置文件之外，OpenID Connect 还有一个隐式客户端配置文件，它构建在来自 OAuth 2.0 的隐式授权之上.此配置文件允许将令牌直接传送到浏览器内/Javascript 客户端，而无需涉及后端.

In addition to the Basic Client Profile that uses the Authorization Code grant, OpenID Connect has an Implicit Client Profile that builds on the Implict grant from OAuth 2.0. This profile allows for tokens to be delivered directly to in-browser/Javascript clients without involving a backend.

这篇关于单页应用程序 (SPA) 的单点登录 (SSO) 解决方案/架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！