选择合适的用户系统 - 各认证协议介绍及cas、keyclock、authz、authing等的对比

本文首发于俺的博客：https://rxrw.me/tech/user-system-compare/

从我刚开始学习互联网方面的编程开始，无论是写什么项目（除了微信公众号的消息收发），用户都是一个耗时间、耗精力而又无法保证开发最终稳定、无法复用的功能。对于每个业务需求，有一半的时间都是去做用户系统。从最开始的原生 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 作为认证条件，由客户端判断条件是否存在，存在则通过验证接口验证用户登录状态，同时返回用户信息，否则进行登录。同时客户端可以自定义登录流程，通过服务端提供的接口进行认证。总体流程如图¹：

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

OIDC（Oauth 2.0 实现）

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