关于 SSO 选型的思考

你在什么时候会去考虑实施SSO？

公司具备开发能力，且内部应用系统林立，烟囱式的系统建设导致内部数据流转困难，业务人员需要登录与记忆几个系统的密码，管理人员需要多次登录来设置各类的权限时，就可以考虑建立SSO来统一人员信息，进一步可以统一权限信息。 这不但是公司基础设施的基础也可以作为自身晋升功绩的一部分，等打通 基础的人员，权限信息后，后续可以进行 中台/平台 化改造，内部功能的改造，(如日志，告警，消息服务…) 来提升效率, 趁机也可以开启整体系统的微服务改造。

什么是 SSO (Single sign-on , 单点登录)？

单点登录是一种身份验证方法 是在多个应用系统中，用户只需要登录(认证)一次就可以访问多个相互信任的应用系统。

一般 sso 体系主要角色有三种： user（多个） web 应用（多个）, sso 认证中心（ 1 个）

一般的步骤为

1. 前提-A应用在认证中心注册

2. 用户点击A应用的统一登录按钮跳转进入认证中心

3. 用户在认证中心认证成功后，携带认证信息跳转回应用

4. 应用获取授权信息，关联自身的用户模块，记录用户登录信息，登录成功

目前的实现方案

基于以上的思路，业界出现了几套通用的方案

CAS(Central Authentication Service) 中央认证服务

国内的话，有各种供应商会给学校，医院，政府，企业提供此类的系统。在github上也有成熟的开源产品可以使用。

各位有对接需求的可以看下 github.com/apereo/phpCAS 这个包

优点：成熟，java 线容易找到大量的系统 缺点：部分产品基于session cookie 机制，技术栈较老 ，系统侵入性强，代码内需要引入其对应的客户端，定制化处理比较麻烦

OAuth2.0 rfc

这类的方案是目前的主流，比如微信，钉钉，QQ 等各类的大厂都有此协议的实现 , 授权码模式的具体实现如下图

()

我们也可以在 GitHub 上找到 大量的 OAuth2.0 的代码，但是 OAuth只规定了授权方式，而并没有涉及到具体用户

大部分的开源项目要不就直接写死了用户表与对应的字段，还提供默认的登录与认证页面，定制化修改较为困难。

要不就是只实现了OAuth 协议，拿过来还要理解整个流程，没法直接使用。

在协议细节上比如微信公众号通过对于 获取 access_token 时会响应 open_id 来让应用可以通过缓存，减少一次请求.

中小型公司的实际需求

在 OAuth2.0 授权码的模式下进一步简化，去除无效字段，减少逻辑

• A : 用户在业务端 主动发起三方认证登录，拼接 app_id 与 redirect_uri 进行跳转

• B : 认证服务对 认证人 进行登录认证

  • 未登录，跳转至登录界面，进行登录认证

  • 已登录进入下一步

• C : 确认已登录人员信息，确认 跳转进入的 应用信息（app_id）与 回调地址（redirect_uri ），生成授权码与跳转链接，并进行跳转

  • 应用信息确认失败的，进入 认证登录大厅页面

• D : 业务端在回调地址（redirect_uri ） 获取 授权码 code，并进行用户是否登录判定，

  • 未登录则去找认证服务，获取 access_token

  • 已登录，则直接进入 系统，流程完成

• E : 服务端 响应此用户对应的 access_token

• F : 业务端 通过 access_token 获取此用户的个人信息

• G : 服务端响应用户信息后，业务端通过此信息，进行自身系统的登录注册相关逻辑

综合考虑

中小型企业，自建一套其实也就一个礼拜的功夫。自己的 UI 界面，与对应服务，定制化与扩展性肯定让你们老板满意。后续有时间的话，我可能会考虑用 golang 写一套后端相关 API。 我更新了一些php日常用得到的Dockerfile, github.com/whyiyhw/work_dockerfile 有问题可以跟我留言~

接下来，我会花上一段时间去更新 golang 相关的内容，其实 golang 算起来跟 php 也是互补，对抗 java 生态的伙伴吧，关键词少，看起来简洁而不简单，我们好好过一遍 golang 来弥补 php 所刻意掩盖的web程序开发的复杂性与细节。