从我刚开始学习互联网方面的编程开始，无论是写什么项目（除了微信公众号的消息收发），用户都是一个耗时间、耗精力而又无法保证开发最终稳定、无法复用的功能。对于每个业务需求，有一半的时间都是去做用户系统。从最开始的原生 PHP 手写笨拙的注册流程和表单，到 ThinkPHP（呕），再到后来的 Laravel 开箱即用的认证模块——虽然说是开箱即用，但国外的邮箱策略和国内的手机号、微信授权功能对比，开发成本还是很大的。并且，对于多产品来说，用户信息的集中也是个必要的功能。所以，相对于开发 N 多个用户系统，不如使用单一的用户系统，然后从其他的系统中通过 token、cookie 等方式进行同步维护状态。这也是我们常说的单点登录（Single Sign-On，SSO）。
无论是作为一个企业，还是一个有小项目的开发者（Both of me），都需要有一个合适的用户系统做支撑。写项目至今，接触过的认证方式和认证系统，综合对比一下。
协议
用户中心系统作为服务端，肯定是要跟客户端进行对接来授权&获取用户信息的。目前大致流行的有 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 的出现抢了它的风头。简介可以参考维基百科： 安全断言标记语言 ，其官网（没有找到官网）。
其他
此外，还有很多用户认证的协议如 Active Directory、Kerberos 等大大小小的协议，在此不一一列举。
框架 & 平台
很多框架或语言本身提供了搭建 SSO 的工具、脚手架，如 Laravel Passport、Go Auth Server 等，在此不一一列举，基本都是基于 OIDC 协议进行开发的。而支持单点登录的客户端如 Confluence（私有部署版）、Gitlab（私有部署版）、Laravel、WordPress（有个收钱很贵的插件）等，也都是支持 OIDC 的，其中前两者也支持 LDAP，Gitlab 也支持 SAML 协议。讲道理，自己开发最快的方式可能还是基于 OIDC 协议进行认证授权吧。
在这里整理一下自己尝试过的 SSO 平台，其中包括开源、收费和云原生的，不争高低，合适就好。
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 的 yaml 格式文件。因此，如果你想用 MySQL 作为存储引擎，那么你需要引入mysql-connector然后再在 yaml 中配置好数据库连接、表结构等信息。而注册等功能需要通过 overlay 的方式进行扩展。而 overlay 我是尝试过的，用起来可以说是相当复杂。其自定义后的 Docker 镜像也是要重新编译的。
总而言之，CAS 本身是一个十分强大的用户认证系统，相关开源的插件也很多。但其因为过于强大而专一，导致我们平时很需要的额外功能反倒不支持，想把 CAS 作为生产环境使用将会有很大的工作量。而且文档也并不是很详细。接入 CAS 需要其支持客户端语言，如 PHP-CAS 等。
Keycloak
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，而我们可能只需要一个昵称，取消前两者的必填属性就需要一定的开发了。
这里是我同事写的 Keycloak 的基础搭建过程：https://zhuanlan.zhihu.com/p/411062890
目前 keycloak 的扩展基本跟不上其更新速度，基本都停留在 12.0.1 的版本。我用了到目前三个星期的时间来适配不同的插件，包括 oauth、短信验证等。这里可以放出来一个看看：https://github.com/rxrw/keycloak-justauth是基于 justauth 让 Keycloak 支持国内数十种平台的第三方授权登录。
Demo: https://auth.iuv520.com/auth/realms/test/account/#/，我内置了一个通用的 key & secret，感兴趣的同学可以自己搞个客户端来体验一下。
|
|
auth0
与前两个不同，auth0 是国外一个云原生（Cloud Native）用户认证系统，要 💰 的商业化平台。免费版可以支持 7000 用户。作为一个云原生项目，特点就是不需要存储、不需要很多开发就可以使用（登录 UI 可以自定义）。但是对于用户系统，把自己公司的用户数据放到别的平台，可能是需要思考一下。登录流程会走 auth0 自己的服务器，虽然可以自定义域名，但本质没有改变，对于国内用户来说速度无法接受。因此自己玩耍一下还可以。
不是要搭建自己的用户平台么，怎么用上人家的了..
authing
这是国内少有的还比较成型的身份认证系统，开发语言 NodeJS。与 auth0 类似，其也是一个云原生平台。虽说不用服务器，每月的价格也够一台不错的阿里云服务器了。
整体的架构和 Auth0 差不多，第三方授权登录都是微信等国内常用的授权方式。
也是各种用户数据存储在第三方，难道真的有企业会愿意把自己的用户信息放在别人那里管么。因此支持私有部署，不过就之前与其进行对接的经历，感觉系统内部的代码其实很乱，基本私有部署也没什么定制化的空间。
总结
其实真正开源的用户系统也就 CAS 和 Keycloak 两家比较完善且流行的。如果有特别严重的定制化需求，建议还是采用自己开发的方式吧。毕竟国外的用户系统不一定合我们的胃口，而国内的某些平台吃相也是真的难看。如果定制化需求没那么严重，可以在现有开源项目的基础上扩展，那是最好的了。我现在就是在 Keycloak 的基础上进行的扩展，感觉经过一定修改和兼容后，产品可用性还是很强的。