你体验过跟 CTO 解释 refresh_token 的无奈吗？

职场出现信任危机以后合作会非常痛苦。建议跑路。

真是，为了安全，带来多少乱七八糟的事情

不是定时器自动续的么

我接触到一半是放在 Redis 里，取到就用、取不到就续一个吗🤔这个不算判断吧

一些小公司的 cto 可能只是在业务上表现出一点技术能力让老板赏识
有的只是在他自己擅长的领域里有点突出
实际上技术广度上很欠缺，当 cto 实在是名不副实

客户端和服务端的时间可能不一致，加上过期时间临界点问题，稳妥做法是客户端有 token 就直接请求，调用时 catch 401 重新 auth 后 retry 请求

到一些很细节的地方，就算现在很高 level 的人也会有一些盲区。我还记得曾经还是个小年轻的时候，给一个技术大佬解释什么是 Basic authentication ，他之前完全对这没概念。
这过程也看得出人品，知道自己有盲区，还会谦虚学习的人才值得追随。

那你当 cto 呗，你能力肯定比他强

@Tom Brown 起码能听别人介绍，有些是不听，只基于自己的认知

那有啥的我的经理连 git 是什么都不知道，但术业有专攻，该擅长的擅长就行

豆包：这个场景非常真实，CTO 笑不是说你错了，是**“每次请求都在业务代码里判断过期” 这个方案，在工程上很土、有坑，不是最优解**。

opus 当个裁判就行了。ai 时代，争论这些细节没什么意义，要么就是故意针对

@Tom Brown
@陈军平
同款，完全不听你说，我不要你觉得，我要我觉得

直接怼回去呗，你也一声冷笑，再加一句，笑 nm 笑

干嘛非要说服他呢, 本来就是领导负责判断 你负责执行, 出了问题也是他背锅

可以解释下认证服务自动续约，肯定是封装好的，这种如果是不需要安全审计和做甲方的项目，自己内部用的项目随便怎么玩呗，他眼中登录估计就是比对一下凭证对不对，或者是 api-key 这种？没有其他中间环节

我还遇到非得死犟嘴让我最上不了台面的功能，都说不合规还得上线，得，平台打回后就蔫了吧唧一个人在那无能狂怒

有了 ai 后这个毛病更过分，自己让 ai 跑了几十万行的代码丢给我们让我们编译部署和修改，改你妈的，一个脱离开发几十年的老登天天和 ai 互相暧昧意淫

@胡霞 那老哥是没遇见过离谱的，等出问题，他就是一句，当时你们怎么会这么设计呢？

看你这描述，标题是 refresh_token ，内容好像在说 access_token 。
如何内容说的是 refresh_token ，那你们 CTO 笑的对。
如果是 access_token ，那笑的也算对。
不管是哪种 token ， 过期判断不应该在业务层面做，这些在框架或中间件层面就做好了。
如楼上说的，这类场景大部分都在 redis 里，或其它缓存中，过期时间在写入时就设定好了，根本没必要在请求时去判断是否过期。

@Emma Johnson 同款，一模一样，提示风险了，非要上，上了出问题就怼我们

@何霞霞 老哥可能没理解。我们是服务端下发 access_token 和 refresh_token，以及他们对应的过期时间。我们希望客户端做的是在 access_token 快要过期时，用 refresh_token 来获取新 token，这样用户就能无感。

@Emma Johnson 老哥可以看我上一个帖子，真是一模一样

@Lisa Taylor 没老哥硬气。。。

其实不需要每次调用客户端都判断，这样效率太低了，启动的时候检查下就行了，或者当请求 401 的时候能刷新就刷新下重试，本身客户端的时间也不可靠，每次判断确实很浪费。

要看情况，要看你 token 哪里 什么类型 token ，jwt 可以自己魔改 这样不需要做请求.

古法从 A-Z node.js 写了单位的 SSO 服务器，OIDC 第一次签发会带有 expires_in . gateway 到时候 refresh token 存 redis 过期前提前 1 分钟续命... 这样老请求不会掉，新请求用的都是新 token.

要是单纯嘲讽可以聊一下.... 我们 CTO 说 使用 client_credential 要有/userinfo 端点…… 我也懵逼. 但是经过大量资料 发现他是魔改了. ... 掏出证据就好

@Emma Johnson #18 遇到过业务部门丢过来一个项目，资源加代码就 2GB ，几万行代码全在裸奔，说是她都调好了，让我给她部署上每周稳定产出就行......https://i.imgur.com/e1q9ScT.png

什么魔改啊，access_token 服务器返回过期，再用 access_token 刷新，为啥要每次判断？

都按他的来就行了，年轻人 谦虚点。他说怎么来，你转头就告诉 AI ，让 AI 给你改成他说的就行了。别犟

@Emma Davis #19 很真实。哈哈哈哈

@Emma Davis 客户端不是应该是 401 Unauthorized 时 直接请求刷新吗？

不要说就应该这样，应该是哪个公司，或者哪个开源项目/社区就这样做的，一定要说具体点，一般领导都会说就按照这个来，你上来就说就该这样，显得他太菜了，你举个权威，说明你也是抄的别人的，并非你技术高超，他心理上容易接受，当然你要是看不上他，任何交流方式都随便

赶紧跑路吧，你领导现在处于达克效应的愚昧之巅

@Lisa Martinez 这是真学到了

这种 jwt 签发 token 的方法是 steam 采用的登陆流程，完整的流程在 github/steamkit 有具体实现。登陆前 steam 会先下发一个公钥，用来加密登陆密码，验证成功后下发 accessToken 和 refreshToken ，之后用 accessToken 登陆，refreshToken 续签。

我特么也遇到了同款 cto ， 完全不听劝，我不要你觉得，我要我觉得。 好想跑路啊啊啊啊

你有没有想过时间不同步的问题呢

他想做成什么样就做成什么样，你有钱拿就行了

@Emma Davis #19 会不会出问题, 什么时候出问题都是未知数, 非要把矛盾提前到当下干什么呢?

我这里小作坊是 cto 要求不要过期 我觉得他说的对 谁给我发工资谁说的对

无敌了，一次登录，终身免密

@黄洋 这不叫 jwt ，就是普通 token 认证的流程。另外 jwt 只能用在纯内网，所有在公网环境用 jwt 的都存在安全问题

安全和便利是相对的.

断章取义没有意义。

你发的内容显然是讨论中的一个片段，他都不知道你的完整想法，你也不知道他质疑的点究竟是什么；你也没提到这个辩论最后的结论和结果。

> 加一句，cto 亲自下场的原因，是因为他酒场上输了，他要在职场上证明他 NB ，然后去说那些人水平差
这也是只有结论没有过程。

说实话我对 OP 信任度不高。

一次获取终身享受的方案有很多啊

用什么手段才能把 cto 拉到和开发人员讨论 refresh token 的层次?

人家说咋做你就咋做，舔好了比啥都强，你要舔成嫡系活都不用干了，不就上个班么。为了啥，不是比谁代码写得好。最起码你我的层次还没到这个水平

职场就应该“专业”，任何事情都有得商量，不涉及钱的问题，排除一切情绪起伏

“”那每次请求接口，我还得判断 token 过没过期？“
”对的，这样在 xx 方面，能避免 xx 问题，而已也不容易 xx ，安全性高一点。如果 token 泄漏，会 xx”

refresh_token 机制真的毫无意义

token 就能一直用，一次获取，
终身享受在同一台设备没任何问题。
本身就是业务设计不超前，一切以用户体验为主。 技术佬拿钱做事就行了，差不多争辩下 不服就去干，继续干就老老实实做。ai 时代来临 写了十年代码还没认清自己干嘛的？ 或者说在现有的软件架构体系下，90%编码员应该具备服从性。 科研类的东西 公司是做项目盈利 不是慈善给程序员们学习成长 验证技术实施的。