@CokeMine 你这么一说我就明白了，意思就是 ASN 和 IP 分配相当于君子协定，实际操作时只要你的路由器支持，那么就可以随意设定 ASN 和公网 IP 。

那我请教一下，两个人使用了同样的 ASN 和公网 IP 并且会有什么后果，比如一个 IP 分配给了中国移动，但是工作失误忘记记录已经分配出去了，又被分配给了中国电信，它们都向公网广播这个 IP 位于自己网络下的的某个自治域，这时对网络和分配到这两个 IP 的用户而言，会产生什么样的后果

@cnbatch 你这和没说一样啊，走什么流程最终都要在物理层面落地啊，现在就是不明白这一步怎么操作

@cnbatch 所以人为分配要怎么分配，要使用什么专用设备还是软件实现

同 95 年，8 年经验，你这简历比我丰满，我都没啥拿的出手的项目

@cmai 看了他主页，好抽象

@nobject 除了 id_token 读取信息之外，他们一般还会有一个同步器和连接器，不同系统叫法不一样，同步器就是从你现有的用户系统读取用户，连接器就是你的用户信息发生了变动，比如密码、email ，会同步到应用系统，一般是 sso 后端通知应用后端，否则你的 sso 里修改了 email ，其他应用要再次授权获取 token 时才能知道 email 修改了，用了连接器的话就可以直接同步过去了。

@nobject 你可以安装一个 maxkey 调试一下，或者 IDaas 厂商，authing 、阿里云 IDaas 、华为 OneAccess ，都可以免费试用，你接入一个应用调试一遍就好理解了，使用一下他们现成的产品也可以帮助你更好的构思自己的项目。华为的 OneAccess 比较简单好理解

@nobject 第一个问题，userId 是唯一标识，你可能还需要用户名、email 之类的，要啥你 jwt 里带啥就行了。第二个问题，没错，因为 oidc 本来就是在 oauth 里多返回了个 id_token 而已，其他没啥区别。

@nobject access_token 用于授权，因为 oidc 是基于 oauth2 的，而 oauth2 协议原本就有 access_token ，这个用于你更多的功能授权，比如你的 sso 里有一个余额，你在 scope 里授权了余额相关的功能，那么你的 access_token 就可以操作你 sso 提供的余额相关接口，access_token 的格式既可以是 jwt 格式，也可以是自己生成的随机字符串。

id_token 固定为 jwt 格式，里面可以解析出基础用户信息。

针对你问题里的 id_token 怎么使用这个问题，基本与 cas 协议类似, 流程大概如下:
假设现在有商城 shop.qq.com ，后台需要接入员工 sso

1 、员工访问 shop.qq.com/admin ，未登录重定向至 shop.qq.com/admin/login
2 、shop.qq.com/admin/login 判断未登录，重定向至 sso.qq.com/oidc/login?一堆参数
3 、sso 登录后重定向回 shop.qq.com/admin/login?code=xxxxxxxx
4 、shop.qq.com/admin/login 页面通过 code 交换到 access_token 和 id_token
5 、商城系统解析 id_token (或者使用 access_token 去 sso 的用户信息 api 交换)，获得用户信息
6 、商城系统从用户信息读取唯一标识，比如 user_id, 判断本系统 user 表是否存在(如果不存在写入 user 表)，，然后写入登录信息

这个流程其实 cas 协议没有太大的区别，只是参数和接口发生的了变化。
和 oauth2 的区别就是用户端省略了点击确定授权，然后读取用户信息可以省略掉从 op 读取，而可以直接从 id_token 解析，除此之外基本就和你接入 QQ 登录一样没有区别

离不开上面的妹妹，卸载了几次，晚上又装回来

@FuryBean OIDC 和 Cas 其实都适合内部 sso ，因为 git 、oa 等很多内部应用是第三方厂商开发的，所以需要一个开放统一的认证协议。如果你的 sso 是 to c 的话，不如自定义 sso 协议来的方便。你可以观察 qq 淘宝这些大厂商，他们做起来的时候，还没有这些玩意，所以他们的 to c 的账户系统都是自定义协议的，而小米、vivo 、oppo 的 sso ，你可以去登录页面观察参数，依旧没有使用 cas 和 oidc ，而是选择了自定义的方式，不过原理都是差不多的。

但是这些厂商的内部员工用的 sso 都支持 cas 这些，应该就是为了兼容采购的第三方企业应用。

2C 的话，自定义协议更方便也更符合自己公司的需求

access_token 是给你的 a 应用和 b 应用的后端用的，而不是前端，你的 A 应用前端和 A 应用后端交互你需要自己实现。

a 站点登录后 b 站点也自动登录，这个在 cas 和 OIDC 中并没有统一实现，都是你访问要登录的页面时，才跳转到 sso 登录。如果你某个页面，没有登录也可以访问，但是如果 sso 登录了，需要同步登录，常见做法，假设域名为 sso.domain.com
a.domain.com
c.domain.com
sso 登录时，在根域名 domain.com 下写两个 cookie ，一个写明文明文 UID ，一个写 UID 加密字符，应用 a 和 b 后端随时检测这两个 cookie 是否存在，如果存在，且检测加密是否为你的系统生成的 cookie 而不是用户自己乱写入的，则跳转到 sso 认证再跳回当前浏览页面，即可实现非必须登录页面的自动同步登录状态，同理，可以用该 cookie 实现同步退出，a 应用退出后跳转至 sso 退出，sso 删除这两个 cookie ，访问已经登录的 b.domain.com ，该站点检测到根域名下的 cookie 已经失效，清楚当前站点登录状态。

如果应用和 sso 不在同一个域名下，例如:
sso.qq.com
www.qq.com
www.paipai.com
此时，paipai 站点无法读取到 qq.com 下的 cookie ，并不知道用户已经在 sso.qq.com 下登录了，需要手动跳转至 sso.qq.com 认证。常见方案是，sso.qq.com 登录后 iframe 或者 jsonp 方式调用 sso.paipai.com ，sso.paipai.com 会同步在 paipai.com 根域名下写 cookie ，www.paipai.com 检测到这两个 cookie 存在且合法的情况下跳转至 sso.qq.com 认证。

电影没看过，这音乐还真听过，记忆深处，和 Yesterday Once More 一样，但是在哪儿听过是想不起了

你这博客名字，属于直接上报到总书记办公室那种

@wansho 你这是属于现身说法了

@gongshuiwen 你转发的这个帖子很好

@nobodyknows 那是给第三方调用的多 你抓包看他自己的应用有几个用 jwt 的