一般情况下，开展业务的团队需要两套 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