一般情况下,开展业务的团队需要两套 SSO(单点登录)系统,一套面向客户,一套面向团队内部;因为

  1. 面向客户的服务通常存在多个,大部分有登录鉴权或获取客户信息的需要
  2. 面向客户的服务越多,相应的后台管理应用也会越多,需要对操作人作相应鉴权
  3. 多个系统各自实现登录鉴权,既不安全也不高效,因此需要两套 SSO

需要写两套代码吗? 两套 SSO 系统的核心逻辑是一致的,理论上只是相关数据源(用户数据、对接应用数据)不同,因此一套代码通过传参的方式可以满足多个系统运行需求。

一定要写代码吗? 初创团队或个人开发者的资源非常有限,应集中在其核心业务中,SSO 这类的基础服务若占用过多资源显然不划算;类似网络服务器,我们会直接用 Nginx 而不会自己写代码开发一套;因此对 SSO 也可以寻求软件或 SAAS 的方案。

SAAS? 海外有 OKTA,国内有 Authing,功能强大,可以很好满足应用鉴权需求。缺点是需要持续支付费用,Authing 一个面向员工的 SSO 最低需要 ¥7000 / 年(可以买 10 多台轻量级服务器了 😆),自掏腰包的个人或小小团队对费用稍稍敏感,费用会伴随用户数量增加,不付费基本没法用于生产环境;另一个缺点就是对数据存储风险及云服务厂商自身风险的顾虑。选择 SAAS 方案见仁见智,不在本文讨论范畴。

在 GitHub 和 Docker Hub 上搜 SSO,可以看到不少结果,但很遗憾没有我想要的项目。

作为一个创作者,思考着能否低成本实现这个软件开发,达到自此之后少写代码的目的,在满足自身业务需要的同时也可以为他人提供便利。

作为一个使用者,对软件的关注点在于:

  1. 能用。功能可以满足所需
  2. 易用。不希望使用软件前被迫准备运行环境、安装一堆依赖、或额外开发代码
  3. 直观。在安装/使用软件之前可以看到预览的功能效果
  4. 透明。软件虽是一个封装打包的产物,但能看到源码会更有安全感

于是拟定的方案为,通过 Docker 命令进行启动,只需一行命令,Docker 的相关参考:


目前输出了最简功能的软件及其 Demo。

SSO 主服务

SSO Admin