SSO 我调你老味 05: 少一点，再少一点

前言

现在 service 的安全性应该已经很高了，小白决定再写几个服务，比如 servfire。

在进行前期测试的时候，servfire 大受欢迎。可是，这又引出了一个问题：对于 service 的已有客户，怎么能让 Ta 们无缝地迁移过来呢？而且，如果未来还有什么 servwind 要怎么办呢？

总不能新建一个项目就复制一遍已有的数据库吧…

于是，小白想到了借助另外的神力：

Single Sign-On 的中文名字是「单点登录」，它可以让用户在一个「认证中心」登录后，在不同的地方共享这个登录的身份。

如果把前面的内容暂且抛到脑后，对于每个服务 service（OpenID Connect 把这个叫做 Relying Party，但是我们暂且也不管），它们在请求登录的时候应该向「认证中心」发出一个这种请求：

1
2
3
4


{
  "service": "service",
  "wanted_data": ["profile"]
}

用户在「认证中心」登录后，「认证中心」返回一个这种回复：

1
2
3
4
5
6


{
  "status": "this guy is very good",
  "user_id": 1122334,
  "user_role": "admin",
  "user_name": "abaibai"
}

service 接到这个回复后，就可以按照回复里的内容决定是否提供服务、提供何种服务了。

只要不准备考虑现行的业界规范，那小白只需要把 04 的那套逻辑原封不动地搬到「认证中心」那里，再写一套逻辑处理「认证中心」的回复就行。

直到有人跟小白说 ta 想要用咕噜咕噜登录，这就逼着她采用现行业界规范了，也就是

要讲明白这两个东西是什么可是个力气活，小白决定不在这篇故事里面讲。