版权声明:本文为CSDN博主「IDaaS杂谈」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/nidengxia/article/details/109227964

单点登录实现中,系统之间的协议对接是非常重要的一环,一般涉及的标准协议类型有 CAS、OAuth、OpenID Connect、SAML,本文将对四种主流 SSO协议进行概述性的介绍,并比较其异同,读者亦可按图索骥、厘清关键概念。

一、认证与授权的区别

在介绍具体协议之前,有必要先说明“认证(Authentication)”和“授权(Authorization)”的区别。

认证(Authentication)即确认该用户的身份是他所声明的那个人;

授权(Authorization)即根据用户身份授予他访问特定资源的权限。

也就是说,当用户登录应用系统时,系统需要先认证用户身份,然后依据用户身份再进行授权。认证与授权需要联合使用,才能让用户真正登入并使用应用系统。

二、CAS

Central Authentication Service简称CAS,是一种常见的B/S架构的SSO协议。和其他任何SSO协议一样,用户仅需登陆一次,访问其他应用则无需再次登录。

顾名思义,CAS是一种仅用于Authentication的服务,它和OAuth/OIDC协议不一样,并不能作为一种Authorization的协议。

当前CAS协议包括CAS 1.0、CAS2.0、CAS3.0版本,这三个版本的认证流程基本类似。

CAS的认证流程通过包括几部分参与者:

Client: 通常为使用浏览器的用户

CAS Client: 实现CAS协议的Web应用

CAS Server: 作为统一认证的CAS服务器

认证流程大致为:

  1. Client(终端用户)在浏览器里请求访问Web应用example;
  2. 浏览器发起一个GET请求访问example应用的主页https://www.example.com;
  3. 应用example发现当前用户处于未登陆状态,Redirect用户至CAS服务器进行认证;
  4. 用户请求CAS服务器;
  5. CAS发现当前用户在CAS服务器中处于未登陆状态, 要求用户必须得先登录;
  6. CAS服务器返回登录页面至浏览器;
  7. 用户在登录界面中输入用户名和密码(或者其他认证方式);
  8. 用户把用户名和密码通过POST,提交至CAS服务器;
  9. CAS对用户身份进行认证,若用户名和密码正确,则生成SSO会话, 且把会话ID通过Cookie的方式返回至用户的浏览器端(此时,用户在CAS服务端处于登录状态);
  10. CAS服务器同时也会把用户重定向至CAS Client, 且同时发送一个Service Ticket;
  11. CAS Client的服务端收到这个Service Ticket以后,请求CAS Server对该ticket进行校验;
  12. CAS Server把校验结果返回给CAS Client, 校验结果包括该ticket是否合法,以及该ticket中包含对用户信息;
  13. 至此,CAS Client根据Service Ticket得知当前登陆用户的身份,CAS Client处于登录态。

经过上述流程以后,CAS Server和CAS Client都处于登陆态,当用户如果访问另外一个CAS Client 2的时候,用户不需要再次认证,即会跳过5、6、7、8、9这几步,从而达到SSO的效果。

注: CAS 1.0是个非常简单粗陋的协议,在2.0、3.0版本中,Service Ticket的校验结果均为XML格式, 且引入了一种proxy模式(不在本文做深入讨论)。

CAS协议的详细标准定义,请参考:

https://apereo.github.io/cas/6.2.x/protocol/CAS-Protocol-Specification.html

笔者意见:

  1. CAS协议是一个比较简陋单点登陆协议,协议本身比较轻量级也比较容易实现,但是能够解决的场景比较单一;
  2. 杂乱:CAS 3.0又引入了基于SAML对Service Ticket进行校验;
  3. CAS Client和CAS Server之间的互信是通过接口调用的方式来建立, 没有任何加密/签名机制来保证进一步的安全;
  4. 缺乏校验CAS Client自身身份的机制;
  5. 市面上实现了CAS协议的应用并不多,笔者也不推荐这种协议。

三、OAuth 2.0

谈到OAuth, 通常是指OAuth 2.0协议,它是一种Authorization协议并不是一种Authentication协议,虽然OAuth 2的流程中只描述了Authorization。但是在实际使用中,Authorization脱离Authentication并没有任何意义。

OAuth 2.0解决的主要场景是: 第三方应用如何被授权访问资源服务器。整个流程参与者包括几个组成部分:

  • Resource Owner: 资源拥有者,通常为终端用户
  • Resource Server: 资源提供者
  • Authorization Server: 授权服务器
  • Client: 请求访问服务访问的应用

抽象的授权流程大致为:

假定一个在线音乐服务,用户zhangsan想通过某音视频播放软件来播放在线音乐, 但是在播放音乐之前,该音视频软件必须得通过YuFu(即玉符IDaaS)认证授权,得到zhangsan的同意之后才能访问在线音乐。

在这个场景中,zhangsan为Resource Owner, 在线音乐服务为Resource Server, Client为某音视频播放软件,YF作为Authorization Server。

  1. 音视频软件向zhangsan发起授权请求,请求zhangsan同意访问在线音乐服务;
  2. 根据不同的授权模式,zhangsan同意该授权,且返回一个”授权”给音视频服务;
  3. 音视频服务携带zhangsan的授权,请求YF颁发一个access_token, 用于访问在线音乐;
  4. YF校验音视频服务自身的合法性之后,颁发access_token;
  5. 音视频服务携带access_token, 代表zhangsan请求访问在线音乐;
  6. 在线音乐服务校验完access_token以后,提供音乐服务. 播放器开始播放音乐。

上述是一个抽象的授权流程,而在具体实现中,在前三步中会有几个变种,即不同的授权模式,常见的授权模式包括:

  • Authorization Code Grant: 授权码模式,最为常用,最安全,强烈推荐;
  • Implicit Grant: 适用于SPA应用,已经不再推荐使用,被PKCE模式所替代;
  • Resource Owner Password Credentials Grant: 需要把用户的用户名和密码暴露给Client;
  • Client Credential Grant: 整个流程没有用户的概念,适用于服务端->服务端调用的场景。

可以发现在整个流程中,音视频播放器并不需要知道zhangsan的密码,只是需要得到zhangsan的授权就可以访问在线音乐,而整个授权是由Authorization Server来负责。

本文并不会展开讨论Authorization Code模式,详细协议文档定义请参考:

https://tools.ietf.org/html/rfc6749

笔者意见:相比CAS协议,OAuth2.0不同的授权模式能够解决更多的场景,更安全、更流行,且通过PKCE模式能够实现移动端的单点登录,这个是其他SSO协议都不具备的(PKCE模式参考资料:https://tools.ietf.org/html/rfc7636)。

四、OpenID Connect

OpenID Connect简称OIDC,是基于OAuth2.0扩展出来的一个协议。除了能够OAuth2.0中的Authorization场景,还额外定义了Authentication的场景,可以说OIDC协议是当今最流行的协议。

相比OAuth2,OIDC引入了id_token等和userinfo相关的概念:

整个OAuth2协议,只是定义了access_token/refresh_token,但是这俩token只是为了保护Resource Server的,并没有Resource Owner的身份信息;

OIDC引入了id_token的概念,用这个特殊的token来表示这是Resource Owner的身份证:

标准化id_token的格式:即大家熟知的JWT;

标准化id_token的内容:Standard Claims

参考:https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims

OIDC引入了关于如何获取详细userinfo的Endpoint;

OIDC定义了类似于SAML Metadata的Discovery接口,俗称well-known接口:

参考:https://openid.net/specs/openid-connect-discovery-1_0.html

OIDC协议的登陆授权流程和OAuth2.0基本类似, 整个流程的参与者也类似,只不过换了个术语:

OpenID Provider:简称OP,负责认证和授权

Relying Party:简称RP,OAuth 2.0中的Client

可以说OIDC协议是目前最主流的SSO标准协议,且对开发者友好,实现起来比较简单。

详细协议标准定义参考:

https://openid.net/specs/openid-connect-core-1_0.html

五、SAML 2.0

SAML协议全称为Security Assertion Markup Language,它是一个基于XML的标准协议。SAML标准定义了身份提供者(Identity Provider)和服务提供者(Service Provider)之间,如何通过SAML规范,采用加密和签名的方式来建立互信,从而交换用户身份信息。

SAML是一个非常古老的Authentication的协议,在早期B/S架构的企业级应用中非常流行。

SAML协议非常庞大,定义了很多optional的细节(即不是必须实现)。但这个也是双刃剑,这一点恰恰也是SAML协议的缺点,作为实现者,必须得同时兼顾这些optional的细节,给开发者带来较大的挑战。

技术上,SAML协议基于XML,以Assertion的方式,通过签名和加密交换用户身份信息. 这一点和OIDC协议中的ID_Token类似(采用签名/加密的id_token来交换用户身份)。

SAML流程的参与者包括Service Provider(SP)和Identity Provider(IDP)两个重要角色,且整个流程包括如下两个使用场景:

  • SP Initiated: 服务提供者主动发起
  • IDP Initiated: 身份认证服务器主动发起

下面是大致的认证流程:

  1. End User从浏览器中请求访问某SP:https://www.example.com ;
  2. https://www.example.com发现用户未登录,则发起SAML的AuthnRequest请求至IDP, 用户浏览器跳转至IDP页面;
  3. IDP发现用户处于未登陆状态,重定向用户至IDP的登陆界面,请求用户进行身份验证
  4. 用户在登陆页面中进行身份认证, 通常情况下需要校验用户名和密码;
  5. IDP校验用户身份,若成功,则把包含着用户身份信息的校验结果,以SAML Reponse的形式,签名/加密发送给SP;
  6. SP拿到用户身份信息以后,进行签名验证/解密,拿到明文的用户身份信息,此时SP处于登陆状态,可以对用户提供服务。

可以看到,在整个流程中,IDP是负责颁发用户身份,SP负责信任IDP颁发的用户身份, SP和IDP之间的信任关系是需要提前建立的,即SP和IDP需要提前把双方的信息预先配置到对方,通过证书信任的方式来建立互信。

SAML协议的标准定义可参考:

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

六、各协议简单对比

上面简单介绍了主流的几种SSO协议,本质上它们大同小异,都是基于中心信任的机制,服务提供者和身份提供者之间通过互信来交换用户信息,只是每个协议信息交换的细节不同,或者概念上有些不同。

最后,通过一个简单对比表格来总结本文重点内容: