大型网站用户表设计 第1篇
以下是 OIDC 授权码模式的交互模式，你的应用和 OP 之间要通过这样的交互方式来获取用户信息。
我们的 OIDC Provider 对外暴露一些接口
每次调用这个接口，就像是对 OIDC Provider 喊话：我要登录，如第一步所示。
然后 OIDC Provider 会「检查当前用户在 OIDC Provider 的登录状态」，如果是未登录状态，OIDC Provider 会弹出一个登录框，与终端用户确认身份，登录成功后会将一个「临时授权码」（一个随机字符串）发到你的应用（「业务回调地址」）；如果是已登录状态，OIDC Provider 会将浏览器直接重定向到你的应用（「业务回调地址」），并携带「临时授权码」（一个随机字符串）。如第二、三步所示。
每次调用这个接口，就像是对 OIDC Provider 说：这是我的授权码，给我换一个 access_token。如第四、五步所示。
每次调用这个接口，就像是对 OIDC Provider 说：这是我的 access_token，给我换一下用户信息。到此用户信息获取完毕。
为什么这么麻烦？直接返回用户信息不行吗？
因为安全，关于 OIDC 协议的安全性，又可以展开很大的篇幅，现在简单解释一下：code 的有效期一般只有十分钟，而且一次使用过后作废。OIDC 协议授权码模式中，只有 code 的传输经过了用户的浏览器，一旦泄露，攻击者很难抢在应用服务器拿这个 code 换 token 之前，先去 OP 使用这个 code 换掉 token。而如果 access_token 的传输经过浏览器，一般 access_token 的有效期都是一个小时左右，攻击者可以利用 access_token 获取用户的信息，而应用服务器和 OP 也很难察觉到，更不必说去手动撤退了。如果直接传输用户信息，那安全性就更低了。一句话：避免让攻击者偷走用户信息。
大型网站用户表设计 第2篇
事实上，code 可以直接发送到后端，然后在后端使用 code 换取 access_token。这里我使用 postman 演示如何通过 code 换取 access_token。
你可以使用 curl 命令来发送 HTTP 请求：
获取到 access_token 之后，我们可以使用 access_token 访问 OP 上面的资源，主要用于获取用户信息，即「你的应用」从你的「用户目录」中读取一条用户信息。
你可以使用 curl 来发送 HTTP 请求：
到此，App 1 的登录已经完成，接下来，让我们看进入 App 2 是怎样的情形。
大型网站用户表设计 第3篇
用户已经在 App 1 登录时与 OP 建立了会话，User ←→ OP 已经是登录状态，所以 OP 检查到之后，没有再让用户输入登录凭证，而是直接将用户重定向回业务地址，并返回了授权码 code。
同样，App 2 使用 code 换 access_token
curl 命令代码：
再使用 access_token 换用户信息，可以看到，是同一个用户。
curl 命令代码：
到此，我们实现了 App 1 与 App 2 之间的账号打通与单点登录。
到目前为止，看起来还不错，我们已经实现了两个应用之间账号的统一，而且在 App 1 中登录时输入一次密码，在 App 2 中登录，无需再次让用户输入密码进行登录，可以直接返回授权码到业务地址然后完成后续的用户信息获取。
现在我们来考虑一下退出问题
这个问题实质上是「登录态的管理问题」。我们应该管理「三个会话」：User ←→ App 1、User ←→ App 2、User ←→ OP。
当 OP 给 App 1 返回 code 时，App 1 的后端在完成用户信息获取后，应该与浏览器建立会话，也就是说 App 1 与用户需要自己保持一套自己的登录状态，方式上可以通过 App 1 自签的 JWT Token 或 App 1 的 cookie-session。对于 App 2，也是同样的做法。
当用户在 App 1 退出时，App 1 只需清理掉自己的登录状态就完成了退出，而用户访问 App 2 时，仍然和 App 2 存在会话，因此用户在 App 2 是登录状态。
刚才说到「单点登录」，与之相对的就是「单点登出」，即用户只需退出一次，就能在所有的应用中退出，变成未登录状态。
最先想到的是这种方式，我们在 OIDC Provider 进行登出。
之后我们的状态是这样的：
好吧，其实没有任何效果，因为用户和 App 1 之间的会话依然保持，用户和 App 2 之间的会话同样依然保持，所以用户在 App 1 和 App 2 的状态仍然是登录态。
所以，有没有什么办法在用户从 OIDC Provider 登出之后，App 1 和 App 2 的会话也被切断呢？我们可以通过 OIDC Session Mangement 来解决这个问题。
简单来说，App 1 的前端需要轮询 OP，不断询问 OP：用户在你那还登录着吗？如果答案是否定的，App 1 主动将用户踢下线，并将会话释放掉，让用户重新登录，App 2 也是同样的操作。
当用户在 OP 登出后，App 1、App 2 轮询 OP 时会收到用户已经从 OP 登出的响应，接下来，应该释放掉自己的会话状态，并将用户踢出系统，重新登录。
刚刚我们提到 OIDC Session Management，这部分的核心就是两个 iframe，一个是我们自己应用中写的（以下叫做 RP iframe），用于不断发送 PostMessage 给 OP iframe，OP iframe 负责查询用户登录状态，并返回给 RP iframe。
让我们把这部分的代码加上：
大型网站用户表设计 第4篇
OIDC 的全称是 OpenID Connect，是一个基于 OAuth 的轻量级认证 + 授权协议，是 OAuth 的超集。它规定了其他应用，例如你开发的应用 A（XX 邮件系统），应用 B（XX 聊天系统），应用 C（XX 文档系统），如何到你的「中央数据表」中取出用户数据，约定了交互方式、安全规范等，确保了你的用户能够在访问所有应用时，只需登录一遍，而不是反反复复地输入密码，而且遵循这些规范，你的用户认证环节会很安全。