有房有车，还有现金流 300W ，难道躺平不够么？还有啥好焦虑的，光 300W 存余额宝，一年也可以 6-7w 吧，更何况现在工作又没丢

大多数考核都是看领导的喜好，上面跟谁关系好就给谁打高分。
而且每个人做的业务不一样，有的业务产出明显，有的业务重调研，产出效果一般。
每个人职级与工资不一样，这是一个重要的维度其实，但好多可能都放在一起去考核。
所以有这么多不确定因素在，这绩效大多数还是形同虚设，最后还是变成领导喜好去打

红利也不是每个人都能吃到，在红利期间，没多跳，就吃不到。还有买房，没有格局的也没吃到。每个人都以为时间倒退多少年，就能吃尽那个时代的红利，但有没有想过，你是在知道结果的时候去回看的，不是身处在那个时代的人。如果你和马云马化腾一个时代，你就能和他们达到一样的成就么？

最后一天

所以这种小件是有相关的旗舰店还是啥，怎么筛选靠谱的店？ 去年疫情放开，在 pdd 上买了温度计，结果温度计都上不了 36 度...坑得很

如果要使用 markdown ，把 confluence 给排除了，那个 markdown 插件很难用，而且样式很难看

@xiaomada 嗯，好的，非常感谢，我去体验一下你上面说的一些 idaas 产品，加深一下相关概念的理解。

@xiaomada id_token 按你的说法，只用于解析出来 userId ，如果子系统 user 表不存在，则写入到 user 表，然后子系统自己想怎么处理系统会话，它自行处理，其实这时候已经与 id_token 就无关了？ 还有 id_token 与 access_token 的区别在于本身包含了用户的一些信息，但 access_token 如果需要获取用户信息的话，还需要通过 userinfo endpoint 去获取一次，如果本身不介意再去获取一次的话，其实可能就不需要 id_token 了？我这样理解对么？

@xiaomada 谢谢，不同域名下的实现方式对我很有帮助。对于单点登录与登出，oidc 的 core 协议里确实没有，但有几个补充协议，好像通过前端通道实现的方式和你下面说的不在同一个域名下的实现方式很类似，就是需要 iframe 去做辅助同步通知到其他域。

基于 oidc 协议的，最后返回的 id_token ，我在想，如果使用传统的 cookie + session 的方式，那他协议返回的 id_token 到底怎么使用呢？看了一些开源的基于 oidc 协议作身份认证的产品，在应用的实现范例大多数是怎么通过授权码去获取到 id_token 这些，就点到为止了

@xiaomada 我们的目标是所有的都会接入到这个账号体系中，包括 gitlab 之后也会接入，但首先是要满足我们整个云平台下的各自子系统的登录，所以最后选择了比较统一的 oidc 协议。

@FuryBean 嗯，这么说流程还是蛮清晰的。但其实我纠结的点在哪呢，就是明明使用 oidc 了，那边也返回 id_token 了，但是这个 id_token 的正确使用指南我 get 不到，你像你说的这个流程，感觉更像是传统的 sso 解决方案，用不用 oidc 其实没啥差别，我请求 oidc.com ，只要告诉应用认证成功和用户信息就 ok 了，应用的 session 自己维护，也不需要和 id_token 有任何关联

@tool2d 开放给第三方应用的确实得传 access_token ，但我现在的应用场景是单点登录，我们一个大平台，里面可能有各个子系统，这些系统其实都不算是第三方的应用，理论上是属于我们公司自己的产品，oidc 这边其实就是要做一个统一认证平台，在 api 的授权访问这块，其实有 rbac 的鉴权模块统一处理的。从需求方面，我觉得我们可能用的是 id_token, 不是 access_token

@tool2d 谢谢，看这图明白了点，id token 是用于认证，access token 是用于 api 访问权限判断。那我请求一个 api ，如果后端去解析 id token 的 jwt ，那前端不是得把 id token 与 access token 一并传给后端？

我当时失业是领了，失业的时候不领，那啥时候领呢。
五险对我来说，只有医保是重要的，但失业金会自动续医保，养老的只工满 15 年就行，我觉得能省则省

个人觉得加个黑名单就简单，要踢人，或者后台删除一个用户，用户修改重置密码等，都可以把这个用户加入到黑名单中。依靠 jwt 本身的功能，只能有效期设置短点吧

最近在看 open connect 的规范，如果用户登录，他最终生成 id_token,access_token 与 refresh_token ，而且 token 也是用 jwt ，在我看来，只需要 id_token 到传到后端，jwt 解出用户 id 即可

但像 open connect 的规范这样通过的协议，也会有各种补充的规范用于 session 的管理，作单点登录或登出的，所以有些不是没明白 jwt 的作用，而是单单 jwt 并不好实现这些，还需要中心化的存储去帮忙实现

@learningman O(n^2)？这么吓人，他策略文件我记得是 用户与角色一条，角色与规则一条，最差复杂度不是 O(m*n) 么？角色数量 * 规则数量，还是我想差了？

@israinbow 这个怎么说？

分母+1