sso-技术选型的思考

本文最后更新于:星期二, 一月 25日 2022, 11:22 晚上

关于 SSO 选型的思考

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

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

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

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

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

一般的步骤为

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

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

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

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

07

目前的实现方案

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

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

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

08

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

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

OAuth2.0 rfc

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

09

()

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

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

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

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

中小型公司的实际需求

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

10

  • A : 用户在业务端 主动发起三方认证登录,拼接 app_idredirect_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程序开发的复杂性与细节。


本博客所有文章除特别声明外,均采用 CC BY-SA 3.0协议 。转载请注明出处!