家人们
点击上方蓝字关注我
单点登录(SSO)是一种身份验证过程,允许用户通过一次登录访问多个应用程序。
例:对于一个Google账户来说,我只需输入一次账号和密码,就可以登录Gmail、Google Drive、YouTube等多个Google服务;第三方应用也是类似的操作,我们可以使用这个 Google 账户登录红迪、Medium 等支持使用 Google 身份验证的应用。据我所知 SSO 大概在20世纪90年代就在用了,很多企业使用基于本地的身份验证方案连接内部PC、网络和服务器,这时候大家常用的有轻量级目录访问协议(LDAP)和Microsoft Active Directory(AD)域。
在SSO系统中,这三个点比较重要:
-
身份提供者(IdP):负责认证用户身份的中央系统。常见的IdP包括Microsoft Entra ID、Okta、Ping Identity 等。
-
服务提供者(SP):用户访问的应用程序或服务,比如工作邮箱、Gitlab、CRM 平台等都是,SP 依赖 IdP 进行用户身份验证。
-
SSO服务器:可以理解成 IdP 和 SP 之间的桥梁,处理认证请求和响应。
举个例子,我随便找一个支持使用 Google 身份验证登录的网站:
当我们点击以 Google 账户继续时,我们不需要在 Indeed上新建一组用户名密码,而是当我们点击按钮时,它会把我们重定向到:
accounts.google.com
在这里,假设我们没有预先登录自己的 Google 账户,那就会看到一个登录窗口,用于输入我们的 Google 用户名和密码;如果预先登陆了,会显示类似的界面要求我们授权:
如果授权认证过程成功,Google 会再次重定向回 Indeed,这时候我们就登录成功了。
当我们使用 Google 登录 Indeed 时,从技术上看会有以下步骤:
-
用户请求访问:用户打开Indeed的登录页面,并选择“使用Google登录”作为登录方式。
-
重定向到身份提供者(IdP):Indeed将用户重定向到Google的登录页面,一般就是
accounts.google.com
。 -
Google登录页面:用户看到Google的登录页面,并输入Google账户的凭据(用户名和密码);如果用户已经登录了Google账户,则可能会看到一个授权确认按钮。
-
输入凭据或授权确认:用户输入Google账户的电子邮件和密码,或者点击授权确认按钮。
-
Google验证凭据:
-
Google接收用户凭据:用户输入的凭据通过Google的登录页面提交给Google。
-
Google验证用户凭据:Google的SSO授权服务器接收这些凭据,并在其内部验证这些信息。验证过程包括检查电子邮件和密码是否匹配,以及是否有效。
-
生成 Token:
-
生成Token:如果用户凭据有效,Google的SSO授权服务器会生成一个认证Token。这个 Token 可以是SAML,也可以是 OAuth 2.0 的。
-
访问授权:Google将生成的认证 Token 发送回Indeed。
-
验证 Token:
-
Indeed接收Token:Indeed接收到来自Google的认证Token。
-
Indeed验证Token:Indeed将接收到的Token发送回Google的授权服务器进行验证,以确保令牌的有效性和真实性。Google的授权服务器会确认Token是否有效,并返回验证结果给Indeed。
-
Token生效:如果Token验证成功,Indeed将允许用户访问其账户,并存储会话信息,以便用户在后续的互动中无需再次登录。
SSO 的优势有很多:
-
对用户体验的提升很大,毕竟只需要记住一组账号密码就能使用大部分服务;
-
对安全性有提升,这里要说一嘴,让用户记住几十个不同账户的密码,只会让他把所有的密码都搞成一个,但是如果只让他记一组用户名和密码,那他大概率就会选择一个长且复杂的密码来用...
-
简化访问控制和审计:SSO系统可以根据角色、部门和级别配置访问权限
-
减轻运维负担等等
是吧,优点挺多,可是 SSO 的劣势也不少:
-
单点故障:集中式身份认证都有这个毛病,如果系统挂了,所有依赖它的应用程序和服务都会受到影响;当然也能解决,多地备份,备用系统,混合认证之类的都行。
-
安全风险:
-
用户凭证集中化风险:虽然SSO提高了整体安全性,但它也使得一个密码被盗用时的风险更大,因为攻击者可能同时获得对多个系统的访问权限。
-
攻击目标集中:SSO 一旦被攻破,会对整个系统带来严重的安全隐患。
-
兼容性问题:一些老旧或自建的应用程序可能不支持 SSO 集成(或者要收钱才能支持 SSO,说的就是你 Kibana),需要额外的开发工作来实现兼容。
单点登录(SSO)只是一种身份验证过程,这就像零信任的 Never Trust,Always Verify 一样。所以我们还要说一下 SSO 的登陆模式:
1. Token-Based 模式
-
用户登录时,认证服务器验证用户凭据,并生成一个令牌(如JWT)。
-
令牌包含用户身份信息和签名,确保令牌的真实性。
-
用户在访问应用时,将令牌包含在HTTP请求头中,应用服务器验证令牌的有效性并授予访问权限。
劣势
-
令牌一旦泄露,可能被滥用直到过期。
-
令牌的管理和撤销较有点麻烦。
2. Session-Based 模式
-
用户登录时,服务器生成会话ID,并在服务器端保存用户会话数据。
-
会话ID通过Cookie返回给客户端。
-
客户端在后续请求中包含会话ID,服务器验证会话ID的有效性并提供相应服务。
劣势
-
会话信息存储在服务器,增加一些服务器存储和管理负担。
-
跨域和分布式环境下使用也是麻烦。
3. SAML 模式
-
用户请求访问应用时,应用将用户重定向到SAML身份提供商(IdP)。
-
IdP验证用户身份后,生成SAML断言(Assertion),并通过浏览器重定向返回给应用。
-
应用验证SAML断言,授予用户访问权限。
劣势
-
配置和管理较为复杂,需要理解SAML协议和XML签名,但有很多包能做这件事,整体来讲还可以。
4. OAuth/OIDC(OpenID Connect)模式
-
用户请求访问应用时,应用将用户重定向到OAuth授权服务器。
-
用户在授权服务器上登录并授权应用访问其资源。
-
授权服务器生成访问令牌(Access Token)和ID令牌(ID Token,OpenID Connect特有),返回给应用。
-
应用使用访问令牌访问受保护资源,使用ID令牌获取用户身份信息。
5. Kerberos模式
-
用户登录时,通过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单点登录,一文讲清!
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论