一：介绍
SSO（SingleSignOn）就是通过用户的一次性鉴别登录。当用户在身份认证服上登录一次以后，即可获得访问单点登录系统中其他关联系统和应用软件的权限，同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改的，这意味着在多个应用系统中，用户只需一次登录就可以访问所有相互信任的应用系统。这种方式减少了由登录产生的时间消耗，辅助了用户管理，是比较流行的。
二：几种常见的SSO解决方案
不管前端是（浏览器、APP、小程序），在完成登录之后，我们都需要存储一个认证成功的标识，在后面的请求中，带上这个标识，从而让服务器能够放行进行有效访问。通常在客户端为浏览器里面，我们会使用cookie来进行存储，原因是因为cookie在每次请求之中都会带上，方便前端的管理使用。其他的客户端可能没这么方便得做统一存储与处理（一般都是在每次请求时从Header里面传入凭证进来），对于其他特殊协议(比如websocket)可能会把凭证在参数里面带上。
之所以解释这么多，就是说在我们的认证系统的设计之中，最好是要能考虑到这些情况，下面就介绍几种常见的SSO解决方案:
CAS(Central Authentication Service)
种独立开放指令协议。CAS是耶鲁大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目，它的流程如下:
CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5，6 步中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。在该协议中，所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的安全性。协议
工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
总结: 因为是只有一个认证系统，所以维护起来比较复杂(举个例子: 认证都是在CAS Server,拿企业A和企业B的账号密码都要在这里登录，那你还得分登录企业A还是企业B，认证系统要做特殊化处理，后面再用企业C,企业D还要做而且不一定是账号密码的登录方式，很麻烦，我们写个认证服务还要关心别人是怎么登录的，别人登录后怎么验证的）。
SAML
安全断言标记语言（英语：Security Assertion Markup Language，简称SAML，发音sam-el）是一个基于
XML的开源标准数据格式，它在当事方之间交换身份验证和授权数据，尤其是在身份提供者和服务提供者之间交换。SAML是OASIS安全服务技术委员会的一个产品，始于2001年。其主要更新发布于2005年，但协议的增强仍在通过附加的可选标准稳步增加。SAML解决的最重要的需求是网页浏览器单点登录（SSO）。单点登录在 内部网层面比较常见，（例如使用Cookie），但将其扩展到内部网之外则一直存在问题，并使得不可互操作的专有技术激增。
redirect方式:
post方式:
总结: 作为身份验证使用,实现比较复杂。
OAUTH2
OAuth2.0是OAuth协议的延续版本，但不向前兼容OAuth 1.0(即完全废止了OAuth1.0)。 OAuth 2.0关注客户端开发者的简易性。要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户，要么允许
第三方应代表用户获得访问的权限。同时为Web应用，桌面应用和手机，和智能家居设备提供专门的认证流程。2012年10月，OAuth 2.0协议正式发布为RFC 6749 。
总结: 更加关注于授权。因为登录的维护是交给了第三方程序，第三方程序验证后给到一个凭证，然后通过凭证可以去拿取数据(比如google账号登录，github登录，微信登录等等)，所以它比CAS更适合于互联网上的开发，而CAS适合内部身份验证和授权。
OIDC
OpenID 是一个以用户为中心的数字身份识别框架，它具有开放、分散性。OpenID 的创建基于这样一个概念：我们可以通过 URI （又叫URL或网站地址）来认证一个网站的唯一身份，同理，我们也可以通过这种方式来作为用户的身份认证。
登录一个支持 OpenID 的网站非常简单（即便你是第一次访问这个网站也是一样）。只需要输入你注册好的 OpenID 用户名，然后你登录的网站会跳转到你的 OpenID 服务网站，在你的 OpenID 服务网站输入密码（或者其它需要填写的信息）验证通过后，你会回到登录的网站并且已经成功登录。OpenID 系统可以应用于所有需要身份验证的地方，既可以应用于单点登录系统，也可以用于共享敏感数据时的身份认证。
除了一处注册，到处通行以外，OpenID 给所有支持 OpenID 的网站带来了价值—共享用户资源。用户可以清楚的控制哪些信息可以被共享，例如姓名、地址、电话号码等。
今天，OpenID 作为以用户为中心的身份验证系统已经为数百万的用户提供了服务。在“I Want My OpenID Bounty” 项目的推动下，许多开源项目都迅速的加入了对 OpenID 的支持。
总结：
OIDC使用OAuth2.0的授权服务器来为第三方用户提供身份认证，并将对于的身份认证信息传递给客户端，且可以适用于各种类型的客户端（比如服务端应用，移动APP，JS应用），且完全兼容OAuth2，
所以OIDC既可以用来认证也可以用来授权。(认证是指它需要提供身份认证，授权是会给它返回ticket,然后用ticket可以去取相应数据，但OIDC的身份认证是有标准的(需要双方去满足的，可以说实现了个定义了标准的CAS了))
三：总结
我们实现系统的时候，对外要具备对接SSO标准协议的能力，对内也要提供SSO标准协议的能力。推荐使用OIDC（全面），OAUTH2(使用者多)。
