通俗理解SSO单点登录，一文讲清！

 家人们

点击上方蓝字关注我

单点登录（SSO）是一种身份验证过程，允许用户通过一次登录访问多个应用程序。

例：对于一个Google账户来说，我只需输入一次账号和密码，就可以登录Gmail、Google Drive、YouTube等多个Google服务；第三方应用也是类似的操作，我们可以使用这个 Google 账户登录红迪、Medium 等支持使用 Google 身份验证的应用。据我所知 SSO 大概在20世纪90年代就在用了，很多企业使用基于本地的身份验证方案连接内部PC、网络和服务器，这时候大家常用的有轻量级目录访问协议（LDAP）和Microsoft Active Directory（AD）域。

SSO 中的几个关键部分

在SSO系统中，这三个点比较重要：

1. 身份提供者（IdP）：负责认证用户身份的中央系统。常见的IdP包括Microsoft Entra ID、Okta、Ping Identity 等。

2. 服务提供者（SP）：用户访问的应用程序或服务，比如工作邮箱、Gitlab、CRM 平台等都是，SP 依赖 IdP 进行用户身份验证。

3. SSO服务器：可以理解成 IdP 和 SP 之间的桥梁，处理认证请求和响应。

SSO 的工作流程示例

举个例子，我随便找一个支持使用 Google 身份验证登录的网站：

当我们点击以 Google 账户继续时，我们不需要在 Indeed上新建一组用户名密码，而是当我们点击按钮时，它会把我们重定向到：

accounts.google.com

在这里，假设我们没有预先登录自己的 Google 账户，那就会看到一个登录窗口，用于输入我们的 Google 用户名和密码；如果预先登陆了，会显示类似的界面要求我们授权：

如果授权认证过程成功，Google 会再次重定向回 Indeed，这时候我们就登录成功了。

当我们使用 Google 登录 Indeed 时，从技术上看会有以下步骤：

1. 用户请求访问：用户打开Indeed的登录页面，并选择“使用Google登录”作为登录方式。

2. 重定向到身份提供者（IdP）：Indeed将用户重定向到Google的登录页面，一般就是accounts.google.com。

3. Google登录页面：用户看到Google的登录页面，并输入Google账户的凭据（用户名和密码）；如果用户已经登录了Google账户，则可能会看到一个授权确认按钮。

4. 输入凭据或授权确认：用户输入Google账户的电子邮件和密码，或者点击授权确认按钮。

5. Google验证凭据：

• Google接收用户凭据：用户输入的凭据通过Google的登录页面提交给Google。

• Google验证用户凭据：Google的SSO授权服务器接收这些凭据，并在其内部验证这些信息。验证过程包括检查电子邮件和密码是否匹配，以及是否有效。

6. 生成 Token：

• 生成Token：如果用户凭据有效，Google的SSO授权服务器会生成一个认证Token。这个 Token 可以是SAML，也可以是 OAuth 2.0 的。

7. 访问授权：Google将生成的认证 Token 发送回Indeed。

8. 验证 Token：

• Indeed接收Token：Indeed接收到来自Google的认证Token。

• Indeed验证Token：Indeed将接收到的Token发送回Google的授权服务器进行验证，以确保令牌的有效性和真实性。Google的授权服务器会确认Token是否有效，并返回验证结果给Indeed。

9. Token生效：如果Token验证成功，Indeed将允许用户访问其账户，并存储会话信息，以便用户在后续的互动中无需再次登录。

SSO 的优势和不足

SSO 的优势有很多:

1. 对用户体验的提升很大，毕竟只需要记住一组账号密码就能使用大部分服务；

2. 对安全性有提升，这里要说一嘴，让用户记住几十个不同账户的密码，只会让他把所有的密码都搞成一个，但是如果只让他记一组用户名和密码，那他大概率就会选择一个长且复杂的密码来用...

3. 简化访问控制和审计：SSO系统可以根据角色、部门和级别配置访问权限

4. 减轻运维负担等等

是吧，优点挺多，可是 SSO 的劣势也不少：

1. 单点故障：集中式身份认证都有这个毛病，如果系统挂了，所有依赖它的应用程序和服务都会受到影响；当然也能解决，多地备份，备用系统，混合认证之类的都行。

2. 安全风险：

• 用户凭证集中化风险：虽然SSO提高了整体安全性，但它也使得一个密码被盗用时的风险更大，因为攻击者可能同时获得对多个系统的访问权限。

• 攻击目标集中：SSO 一旦被攻破，会对整个系统带来严重的安全隐患。

3. 兼容性问题：一些老旧或自建的应用程序可能不支持 SSO 集成（或者要收钱才能支持 SSO，说的就是你 Kibana），需要额外的开发工作来实现兼容。

SSO 的工作模式

单点登录（SSO）只是一种身份验证过程，这就像零信任的 Never Trust，Always Verify 一样。所以我们还要说一下 SSO 的登陆模式：

• 用户登录时，认证服务器验证用户凭据，并生成一个令牌（如JWT）。

• 令牌包含用户身份信息和签名，确保令牌的真实性。

• 用户在访问应用时，将令牌包含在HTTP请求头中，应用服务器验证令牌的有效性并授予访问权限。

• 令牌一旦泄露，可能被滥用直到过期。

• 令牌的管理和撤销较有点麻烦。

• 用户登录时，服务器生成会话ID，并在服务器端保存用户会话数据。

• 会话ID通过Cookie返回给客户端。

• 客户端在后续请求中包含会话ID，服务器验证会话ID的有效性并提供相应服务。

• 会话信息存储在服务器，增加一些服务器存储和管理负担。

• 跨域和分布式环境下使用也是麻烦。

• 用户请求访问应用时，应用将用户重定向到SAML身份提供商（IdP）。

• IdP验证用户身份后，生成SAML断言（Assertion），并通过浏览器重定向返回给应用。

• 应用验证SAML断言，授予用户访问权限。

• 配置和管理较为复杂，需要理解SAML协议和XML签名，但有很多包能做这件事，整体来讲还可以。

• 用户请求访问应用时，应用将用户重定向到OAuth授权服务器。

• 用户在授权服务器上登录并授权应用访问其资源。

• 授权服务器生成访问令牌（Access Token）和ID令牌（ID Token，OpenID Connect特有），返回给应用。

• 应用使用访问令牌访问受保护资源，使用ID令牌获取用户身份信息。

• 用户登录时，通过Kerberos票据授予票证（TGT）向认证服务器（KDC）请求服务票据（TGS）。

• 认证服务器验证TGT，并生成服务票据，返回给用户。

• 用户使用服务票据访问应用，应用验证票据的有效性并授予访问权限。

• 太复杂了，需要了解Kerberos协议和基础架构。

安全性方面，Kerberos模式提供最高的安全性，适用于内部网络和高安全性要求的企业级环境；SAML模式也高度安全，适合 B2B集成环境。OAuth/OIDC 一般很常用了，很多互联网和移动应用认证、授权都用它；Token-Based 模式属于安全性一般般的无状态认证，适合分布式系统和微服务架构；Session-Based 模式是传统的Web应用认证方式，安全性依赖于Session ID的保护。

Kerberos模式虽然安全性高，但实现和管理较为复杂，主要适用于内部网络。实际工程中，如果应用需要高安全性，谨慎选择Kerberos，推荐SAML模式；对于互联网和移动应用，推荐使用OAuth/OIDC模式；分布式系统和微服务架构则适合token based的模式；传统Web应用可以采用基于会话的模式，简单易用。

我之前工作一直是外企，所以推荐的产品以外国货为主，国内我知道有一家 Authing 还可以；其实吧这些厂商准确来说应该叫 IDP 服务商，或者说 IAM 服务商。

Microsoft Entra ID（前称Microsoft Active Directory）：与Office 365、Dynamics CRM及其他Microsoft服务无缝集成，而且免费，开一个企业账户啥都不买就可以直接用 Entra ID，我强力推荐微软的，大而全，复杂的一批，还支持外键之类的。

Okta（就是刚发生数据泄露没多久的那家公司）：支持大量应用的一键配置 SSO，简单好用。

Ping Identity：号称自己很灵活，还有强大的移动和API安全选项，适合有点实力想自己搞的企业。

OneLogin（被收购了）

Auth0（也被 Okta 收购了）

最后总结

总体来看，单点登录（SSO）大大简化了用户的身份验证过程，提高了用户体验和整体安全性。通过集中管理的方式，不仅减轻了用户记忆多个账号密码的负担，还简化了企业的访问控制和审计。但是，SSO也面临单点故障和安全风险等挑战，实际落地还是要根据不同的应用场景，评估合适的 SSO 工作模式和产品，才能平衡安全性和开发成本等。

点点赞 点点关注 点点文末广告 抱拳了家人们

创作不易

关注一下

帮忙点点文末广告

原文始发于微信公众号（imBobby的自留地）：通俗理解SSO单点登录，一文讲清！