单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

SSO在大型网站里使用得非常频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证的逻辑搞疯掉。

实现单点登录说到底就是要解决如何产生和存储信任，再就是其他系统如何验证这个信任的有效性，单点登录有不同的实现方式，本次，我们将一起解读一下目前业界常见的几种单点登录的实现技术。

表单代填

表单代填单点登录，是基于表单的单点登录功能。由IAM系统模拟已认证的用户，将已认证的用户的用户名和密码，通过程序自动输入应用系统的登录表单中，并自动提交，完成应用系统的登录。

表单代填单点登录的原理如下：

说明：

1、 用户登录IAM系统。

2、 用户在IAM系统中点击应用系统图标，IAM系统模拟用户自动帮助用户完成应用系统的用户名/密码的输入并提交。

3、 业务系统完成用户名密码的校验，完成登录。

基于Cookie

基于共享同域的Cookie是Web刚开始阶段时使用的一种方式，它利用浏览同域名之间自动传递Cookie机制，实现两个域名之间系统令牌传递问题

基于Cookie的单点登录的实现原理如下：

说明：

1、 用户输入用户名/密码（para/password）登录到。

2、 处理登录逻辑，并且将用户信息通过cookie的方式返回到客户端（加密用户信息）。

3、 用户访问mail.paraview.cn，浏览器自动将用户信息携带到mail.paraview.cn，通过过滤器（filter）处理用户的登录请求。

4、 过滤器从cookie中获取用户信息，登录，返回用户访问界面。这样用户就只登录一次，就访问了两个网站了。

LTPA

LTPA（Lightweight Third-Party Authentication）是IBM的技术标准，在IBM Websphere和Domino等系列产品中使用到该单点登录技术。

LTPA单点登录方式，其实也是基于Cookie的实现方式，在用户登录成功后，系统会生成LTPA的cookie，该Cookie的名称为LtpaToken及LtpaToken2，利用该Ltpa Cookie，可实现在系统间的单点登录。

一个有效的LTPA Cookie能够在同一个认证域中所有服务器被自动认证。此Cookie中包含认证信息和时间戳。这些信息通过共享的3DES Key进行了加密。使用公共密钥/私有密钥进行签名。

LTPA单点登录的机制与基于Cookie的单点登录方式的机制及过程一致，在此就不再重复说明。

SAML

SAML（Security Assertion Markup Language，安全断言标记语言）是一个基于XML的开源标准数据格式，它在当事方之间交换身份验证和数据，尤其是在身份提供者和服务提供者之间交换。

SAML是OASIS安全服务技术委员会的一个产品，始于2001年。其最近的主要更新发布于2005年，但协议的增强仍在通过附加的可选标准稳步增加。

SAML协议单点登录过程如下图：

说明：

1、 用户访问应用（SP）。

2、 应用（SP）检测用户未认证，将用户重定向到IDP进行认证。

3、 用户在IAM（IDP）完成认证，IAM（IDP）生成SAML Token，并将用户重定向到应用（SP）。

4、 应用（SP）得到SAML Token并解析，得到用户身份后，帮助用户完成登录，从而实现单点登录。

WS-Federation

WS-Federation属于Web Services Security 的一部分，是由OASIS发布的标准协议，其主要贡献者是Microsoft 和 IBM。

WS-Federation 1.1 版本发布于2003年, 的1.2版本标准发布于2009年。该协议主要应用在企业服务，并且是在微软自己的产品中主推，其他厂家的产品可能更愿意选择SAML。另外，该标准是基于SOAP的，整个协议虽然功能强大，细节考虑周全，但实现起来会比较重，只有为了能和微软的服务整合，才会优先考虑该协议。

WS-Federation单点登录的机制与SAML的单点登录机制基本一致，在此也不再过多说明，具体可参考SAML的单点登录过程。

CAS

CAS是Central Authentication Service的缩写，认证服务，一种独立开放指令协议。

CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。

CAS协议单点登录过程如下图：

CAS实现说明：

1、 访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。

2、 定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。

3、 用户认证：用户身份认证。

4、 发放票据： SSO 服务器会产生一个随机的 Service Ticket 。

5、 验证票据： SSO 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。

6、 传输用户信息： SSO 服务器验证票据通过后，传输用户认证结果信息给客户端。

OAuth

OAUTH（Open Authorization）协议为用户资源的提供了一个安全的、开放而又简易的标准。OAUTH的不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的，因此OAUTH是安全的。

OAuth的实现如案例如下图：

说明：

1、 用户访问业务系统。

2、 业务系统判断用户没有登录，把用户重定向到IAM进行认证。

3、 用户在IAM系统中完成登录认证，IAM为用户的此次请求创建OAuth code，并带OAuth code返回应用回调地址。

4、 应用获取OAuth code并请求校验，获取Access Token。

5、 应用通过Access Token调用用户接口获取用户信息。

6、 应用得到用户身份，完成用户登录。

OpenID Connect（OIDC）

OpenID Connect是OpenID和Oauth2的合集。除了遵循Oauth2的规范外还要返回ID_Token来验证身份。

ID_Token是符合JWT格式的数据，包含用户身份认证的信息，一般在只需要实现单点登录的情况下，只需要得到ID_Token即可。

ID_Token取得信息一般是不够的，所以一般还会用Access Token去取用户相关的profile信息。

OpenID Connect的实现原理与OAuth2.0基本一致，具体如下：

说明：

1、 用户访问业务系统。

2、 业务系统判断用户没有登录，把用户重定向到IAM进行认证。

3、 用户在IAM系统中完成登录认证，IAM为用户的此次请求创建码，并带码返回应用回调地址。

4、 应用获取码并请求校验，获取ID Token及Access Token。

5、 应用通过得到ID Token及Access Token，通过Access Token调用用户接口获取用户信息（一般在只需要实现单点登录的业务场景下下，只需要得到ID_Token即可，不需要Access Token获取用户的profile）。

6、 应用得到用户身份，完成用户登录。