单点登录(Single Sign On）简称为SSO，用户只需要登录认证中心一次就可以访问所有相互信任的应用系统，无需再次登录。

主要功能：

1. 所有应用系统共享一个身份认证系统
2. 所有应用系统能够识别和提取ticket信息

协议

用户中心系统作为服务端，肯定是要跟客户端进行对接来授权&获取用户信息的。目前大致流行的有 LDAP、CAS、OIDC(基于 Oauth2.0)、SAML 等，此外还有 Kerberos 等不太常见的协议。其宗旨基本一致：浏览器向客户端发起请求，客户端访问用户系统获取 Cookie 或其他认证条件，由用户系统负责登录并将认证后的条件返回给客户端。

LDAP

Lightweight Directory Access Protocol，轻型目录访问协议。这个协议稍微有接触过企业服务的同学可能都不陌生，这是比较古老的认证协议，但至今仍在企业内部和大部分的用户系统中提供支持。LDAP 是文件型存储的，通过 IP 协议进行用户认证授权，层级结构分明，特别适用于公司内部的用户系统。新员工入职时，只需要添加一个 LDAP 成员，就可以访问 wiki、gitlab、oa 等所有系统了。百度、阿里、饿了么等大部分互联网公司内部均采用此协议进行员工管理。具体参考： https://ldap.com/

CAS

CAS 是由耶鲁大学实验室 2002 年出的一个开源的统一认证服务中的标准协议，也是很多企业内部系统登录所使用的标准协议，如阿里巴巴等。作为 C 端登录协议如支付宝、淘宝等。详细协议标准可以参考 https://apereo.github.io/cas/6.4.x/protocol/CAS-Protocol-Specification.html 。其核心是服务端返回 ticket 作为认证条件，由客户端判断条件是否存在，存在则通过验证接口验证用户登录状态，同时返回用户信息，否则进行登录。同时客户端可以自定义登录流程，通过服务端提供的接口进行认证。总体流程如图^1：

使用方也就是 Apereo CAS，此外有少数的语言也按此协议开发了不同的服务端，不过应用甚少。

OIDC（Oauth 2.0 实现）

Open ID Connect 是基于 Oauth 2.0 的开放身份认证协议。Oauth2 本身是一个认证协议，它提供了一个授权流和标准通用协议，其中并没有有关用户身份认证相关的内容。OIDC 在此基础上实现了用户相关的认证，完全兼容 Oauth2.0。所以我们常见的微博、QQ、微信等开放平台，文档概述是 Oauth2.0 协议，其实采用的也是非标准结构的 OIDC，因此大家基本谈到的 Oauth2.0==OIDC。

OIDC 是目前应用比较广泛的用户认证协议，官网： https://openid.net/connect/ 。最基本的是授权码模式，然后支持直接授权流、隐式授权流、密码授权等客户端对等认证、一次性认证等方式进行授权流程。

授权码模式基本流程就是客户端向服务端发起请求，带着 state、client_id、client_secret、redirect_uri、scope 参数请求服务端的授权接口，服务端打开自己的授权页进行授权后，会回调给 redirect_uri 地址，带有 code 参数，客户端通过 code 向服务端换取 access_token，然后就可以拿 token 去做任何事情了。（懒得画图。。）

OIDC 在所有（没有几乎）语言、框架中均有提供，所有的用户系统也都支持，因此这是一个非常广泛使用的协议。我们平时常见的微信授权登录、QQ 授权登录、Github 登录无一不采用此认证方式。

SAML

Security Assertion Markup Language，安全断言标记语言。一个基于 xml 的在不同安全域间进行交换认证和授权数据的协议，是很经典的一个授权协议。因此在大部分的用户系统中，都会有 SAML 协议的支持。不过国内使用的还是偏少，OIDC 的出现抢了它的风头。简介可以参考维基百科： 安全断言标记语言

Apereo CAS

官网：https://apereo.github.io/cas/6.4.x/index.html

这是老牌的 SSO 系统，Java 语言开发，至今仍在积极维护，有完整的发布时间表和维护周期。以下是官网介绍的特性：

Spring Webflow/Spring Boot Java server component.
Pluggable authentication support (LDAP, Database, X.509, SPNEGO, JAAS, JWT, RADIUS, MongoDb, etc)
Support for multiple protocols (CAS, SAML v1, SAML v2, WS-Federation, OAuth2, OpenID, OpenID Connect, REST)
Support for multifactor authentication via a variety of providers (Duo Security, FIDO U2F, YubiKey, FIDO2 WebAuthN, Google Authenticator, Authy, Acceptto, Inwebo, etc.)
Support for delegated authentication to external providers such as ADFS, Facebook, Twitter, SAML2 IdPs, etc.
Built-in support for password management, notifications, terms of use and impersonation.
Support for attribute release including user consent.
Monitor and track application and system behavior, statistics and metrics in real-time.
Manage and review audits and logs centrally, and publish data to a variety of downstream systems.
Manage and register client applications and services with specific authentication policies.
Cross-platform client support (Java, .Net, PHP, Perl, Apache, etc).
Integrations with InCommon, Box, Office365, ServiceNow, Salesforce, Workday, WebAdvisor, Drupal, Blackboard, Moodle, Google Apps, etc.

其可插拔认证支持、多协议支持、OTP 支持等等非常多的功能均是亮点。还是刚才说的，内部系统很多都在使用其二次开发或扩展的 CAS，如阿里巴巴。

部署支持 Docker、原生 war。

开发采用 CAS Overlay 的方式，就是说在第一次部署后，将某个资源文件或 class 文件复制到你的src/main目录下进行二次开发，在 package 的时候会自动将你的文件替换到原有项目中去，实现功能自定义的目的。

最新版的（6.4）CAS 默认的登录界面如下：

 

是使用 Docker 启动的。登录后界面也十分简单，在左侧有相关文档链接的侧边栏。基础启动方法可以参考其他人的文章：https://www.cnblogs.com/zhzhlong/p/11551361.html

CAS 是一个专注于认证的系统，因此——没有注册功能，默认是内存存储用户信息，一切配置均采用 Java 的 yml 格式文件。因此，如果你想用 MySQL 作为存储引擎，那么你需要引入mysql-connector然后再在 yml 中配置好数据库连接、表结构等信息。而注册等功能需要通过 overlay 的方式进行扩展。而 overlay 我是尝试过的，用起来可以说是相当复杂。其自定义后的 Docker 镜像也是要重新编译的。

总而言之，CAS 本身是一个十分强大的用户认证系统，相关开源的插件也很多。但其因为过于强大而专一，导致我们平时很需要的额外功能反倒不支持，想把 CAS 作为生产环境使用将会有很大的工作量。而且文档也并不是很详细。接入 CAS 需要其支持客户端语言，如 PHP-CAS 等。

Keycloak

官网：https://keycloak.org

Keycloak 于 2013 年末发布 1.0-alpha 版，到现在最新版已经是 15.0.2 了，16.0.0 在紧锣密鼓地开发中。这是一个支持比较完整的用户认证系统，由 Java 开发，基于 jboss。

就在写这段的时候，Keycloak 官网发布了一条消息，迎来的新的 maintainer: Tomas Darimont，主要负责 keycloak.X 的开发。

相对于 CAS，Keycloak 没有那么多的协议的支持，认证协议支持 OIDC 和 SAML，将 LDAP 和 Kerberos 作为用户存储协议集成。使用 Freemarker 作为 HTML 模板。内置第三方授权登录。通过 jboss 提供的热加载服务可实现扩展。内置的所有功能都可以扩展。支持注册！原生支持 Postgres、MySQL、SQLite 等数据库引擎。

而且，其默认的登录界面基本没有侵略性。如图：

部署支持 Docker、原生部署等。内置管理控制台，支持多 realm。默认提供一个 Master 的 realm 供整体管理使用，一般我们都会建立自己的 realm。

扩展方式是基于https://www.keycloak.org/docs/latest/server_development/index.html，将要自定义的功能定义为一个 SPI，部署到 deployments 目录里即可。主题也可以自定义，方式是通过编写 base 模板的 css 来实现。上图的主题是内置的keycloak主题。

当然，缺点也是有的，比如支持的协议不够多，用户的存储无法自定义，文档也不够详细～～（到底要多详细的模板才满意）比较重要的是，其用户属性是可以扩展的，但是默认的必填项是无法删除的，比如国外常用的First Name、Last Name，而我们可能只需要一个昵称，取消前两者的必填属性就需要一定的开发了。

MaxKey

官网：https://www.maxkey.top

MaxKey单点登录认证系统，谐音马克思的钥匙寓意是最大钥匙,是业界领先的IAM身份管理和认证产品,支持OAuth 2.x/OpenID Connect、SAML 2.0、JWT、CAS、SCIM等标准协议，提供标准、安全和开放的用户身份管理(IDM)、身份认证(AM)、单点登录(SSO)、RBAC权限管理和资源管理等。

• 标准协议

序号	协议	支持
1.1	OAuth 2.x/OpenID Connect	高
1.2	SAML 2.0	高
1.3	JWT	高
1.4	CAS	高
1.5	FormBased	中
1.6	TokenBased(Post/Cookie)	中
1.7	ExtendApi	低
1.8	EXT	低

• 登录支持

序号	登录方式	支持
2.1	动态验证码	字母/数字/算术
2.2	双因素认证	短信/时间令牌/邮件
2.3	短信认证	腾讯云短信/阿里云短信/网易云信
2.4	时间令牌	Google/Microsoft Authenticator/FreeOTP/支持TOTP或者HOTP
2.5	域认证	Kerberos/SPNEGO/AD域
2.6	LDAP	OpenLDAP/ActiveDirectory/标准LDAP服务器
2.7	社交账号	微信/QQ/微博/钉钉/Google/Facebook/其他
2.8	扫码登录	企业微信/钉钉/飞书扫码登录

登录界面

主界面

总结：

以上谈到的都是开源社区的项目，CAS则重点在用户登录和相关协议的实现，Keycloak和MaxKey除了用户登录和相关协议的实现，更重要的是实现用户生命周期的管理，基于角色用户的访问控制，各有各的优势，具体怎么去选择还需要看具体情况。