专栏首页IDaaS 身份认证管理云平台单点登录协议有哪些?CAS、OAuth、OIDC、SAML有何异同?
原创

单点登录协议有哪些?CAS、OAuth、OIDC、SAML有何异同?

单点登录实现中,系统之间的协议对接是非常重要的一环,一般涉及的标准协议类型有 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为某音视频播放软件,YuFu作为Authorization Server。

  1. 音视频软件向zhangsan发起授权请求,请求zhangsan同意访问在线音乐服务;
  2. 根据不同的授权模式,zhangsan同意该授权,且返回一个"授权"给音视频服务;
  3. 音视频服务携带zhangsan的授权,请求YuFu颁发一个access_token, 用于访问在线音乐;
  4. YuFu校验音视频服务自身的合法性之后,颁发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协议,本质上它们大同小异,都是基于中心信任的机制,服务提供者和身份提供者之间通过互信来交换用户信息,只是每个协议信息交换的细节不同,或者概念上有些不同。

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

搜索“玉符科技”进入官方网站了解更多单点登录、身份与访问管理相关技术

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

登录 后参与评论
0 条评论

相关文章

  • SSO统一身份认证——SSO都有哪些常用的协议

    单点登录(SingleSignOn,SSO),就是通过用户的一次性鉴别登录。当用户在身份认证服务器上登录一次以后,即可获得访问单点登录系统中其他关联系统和应用软...

    cn華少
  • [OIDC in Action] 3. 基于OIDC(OpenID Connect)的SSO(添加Github OAuth 2.0的支持)

    在上上一篇基于OIDC的SSO的登录页面的截图中有出现QQ登录的地方。这个其实是通过扩展OIDC的OpenID Provider来实现的,OpenID Prov...

    blackheart
  • 身份即服务背后的基石

    近期所在部门基本完成了 IDaaS(身份即服务) 系统的改造,故将所涉及到的知识点总结成本文。

    SuperGopher
  • 前后端鉴权方式多个场景与维度对比

    前后端鉴权是一个很大的话题,不同组织的鉴权方式各不相同,甚至对同一协议的业务实现也可能相去甚远。

    后端码匠
  • SAML和OAuth2这两种SSO协议的区别

    SSO是单点登录的简称,常用的SSO的协议有两种,分别是SAML和OAuth2。本文将会介绍两种协议的不同之处,从而让读者对这两种协议有更加深入的理解。

    程序那些事
  • CAS单点登录-简介(一)

    由于工作上的需求,最近在研究CAS单点登录,参看其它博客官网文档。为了记录学习的一些过程,以便后面翻阅也一同给大家分享一下。

    用户1212940
  • 微服务系统之认证管理详解

    微服务大行其道,微服务安全也是非常热门的话题。本文向大家分享微服务系统中认证管理相关技术。其中包括用户认证、网关和 API 认证、系统间和系统内的认证,以及我们...

    yuanyi928
  • 在wildfly中使用SAML协议连接keycloak

    我们知道SSO的两个常用的协议分别是SAML和OpenID Connect,我们在前一篇文章已经讲过了怎么在wildfly中使用OpenID Connect连接...

    程序那些事
  • [认证授权] 4.OIDC(OpenId Connect)身份认证授权(核心部分)

    1 什么是OIDC? 看一下官方的介绍(http://openid.net/connect/): OpenID Connect 1.0 is a simple...

    blackheart
  • Web 单点登录系统

    对于企业内部系统来说,CAS系统是一个应用最广的开源单点登陆实现了,其实现模仿Kerberos的一些概念,例如KDC、TGS等等,都是来自于Kerberos。具...

    张善友
  • IdentityServer4学习及简单使用

    要学习IdentityServer,需要了解下基于Token的验证体系,其中涉及到Token, OAuth&OpenID,JWT,协议规范等。

    Vincent-yuan
  • 在onelogin中使用OpenId Connect Authentication Flow

    onelogin是一个优秀的SSO(Single Sign-On)服务提供商,我们可以借助onelogin的服务,轻松构建SSO程序。

    程序那些事
  • 每日开源 | 告别造轮子,试试这个单点登录框架...

    在企业开发中,我们经常需要处理单点登录的问题,今天推荐给大家一款不错的框架,避免重复造轮子。

    终码一生
  • OIDC 协议及其在 Kubernetes 中的运用

    K8s 中的认证机制大多都是用 ServiceAccount 来做的,虽然 K8s 有 User 的概念,但没有一种资源与“人”对应,所以在 K8s 里做用户管...

    CS实验室
  • 这个安全平台结合Spring Security逆天了,我准备研究一下

    最近想要打通几个应用程序的用户关系,搞一个集中式的用户管理系统来统一管理应用的用户体系。经过一番调研选中了红帽开源的Keycloak,这是一款非常强大的统一认证...

    程序猿DD
  • 组件分享之后端组件——一款基于Golang的认证全套模块Casdoor

    近期正在探索前端、后端、系统端各类常用组件与工具,对其一些常见的组件进行再次整理一下,形成标准化组件专题,后续该专题将包含各类语言中的一些常用组件。

    cn華少
  • Open ID Connect(OIDC)在 ASP.NET Core中的应用

    我们在《ASP.NET Core项目实战的课程》第一章里面给identity server4做了一个全面的介绍和示例的练习 ,这篇文章是根据大家对OIDC遇到的...

    用户1153966
  • Salesforce 集成篇零基础学习(一)Connected App

    https://trailhead.salesforce.com/content/learn/modules/connected-app-basics

    用户1169343

扫码关注云+社区

领取腾讯云代金券