在介绍具体协议之前，有必要先说明“认证（Authentication）”和“授权（Authorization）”的区别。
也就是说，当用户登录应用系统时，系统需要先认证用户身份，然后依据用户身份再进行授权。认证与授权需要联合使用，才能让用户真正登入并使用应用系统。
Central Authentication Service简称CAS，是一种常见的B/S架构的SSO协议。和其他任何SSO协议一样，用户仅需登陆一次，访问其他应用则无需再次登陆。
顾名思义，CAS是一种仅用于Authentication的服务，它和OAuth/OIDC协议不一样，并不能作为一种Authorization的协议。
当前CAS协议包括CAS 1.0、CAS2.0、CAS3.0版本，这三个版本的认证流程基本类似。
CAS的认证流程通过包括几部分参与者:
认证流程大致为:
注: 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
谈到OAuth, 通常是指OAuth 2.0协议，它是一种Authorization协议并不是一种Authentication协议，虽然OAuth 2的流程中只描述了Authorization。但是在实际使用中，Authorization脱离Authentication并没有任何意义。
OAuth 2.0解决的主要场景是: 第三方应用如何被授权访问资源服务器。 整个流程参与者包括几个组成部分:
抽象的授权流程大致为:
假定一个在线音乐服务，用户zhangsan想通过某音视频播放软件来播放在线音乐, 但是在播放音乐之前，该音视频软件必须得通过YuFu（即玉符IDaaS）认证授权，得到zhangsan的同意之后才能访问在线音乐。
在这个场景中，zhangsan为Resource Owner, 在线音乐服务为Resource Server, Client为某音视频播放软件，YuFu作为Authorization Server。
上述是一个抽象的授权流程，而在具体实现中，在前三步中会有几个变种，即不同的授权模式，常见的授权模式包括:
可以发现在整个流程中，音视频播放器并不需要知道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简称OIDC，是基于OAuth2.0扩展出来的一个协议。除了能够OAuth2.0中的Authorization场景，还额外定义了Authentication的场景，可以说OIDC协议是当今最流行的协议。
相比OAuth2，OIDC引入了id_token等和userinfo相关的概念：
可以说OIDC协议是目前最主流的SSO标准协议，且对开发者友好，实现起来比较简单。
详细协议标准定义参考：
https://openid.net/specs/openid-connect-core-1_0.html
上面简单介绍了主流的几种SSO协议，本质上它们大同小异，都是基于中心信任的机制，服务提供者和身份提供者之间通过互信来交换用户信息，只是每个协议信息交换的细节不同，或者概念上有些不同。
最后，通过一个简单对比表格来总结本文重点内容：