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

[PjJustin]

CTO：那每次请求接口，我还得判断 token 过没过期？ 我：就应该这样呀。 CTO 发出一声轻蔑的笑声。

老哥们可能偏了，这个问题的根源不是 refresh_token 的机制问题，而是他觉得只要登录了，这个 token 就能一直用，一次获取，终身享受。

[weixind]

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

[jackerbauer]

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

[nealHuang]

不是定时器自动续的么

[Climber47]

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

[Sezxy]

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

[dddd1919]

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

[Hstar]

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

[refear99]

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

[0987363]

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

[cgpiao]

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

[puzzle1]

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

[fromzero]

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

[PjJustin]

@Hstar
@0987363
同款，完全不听你说，我不要你觉得，我要我觉得

[suloser]

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

[winnerczwx]

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

[yangwa]

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

[jackOff]

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

[jackOff]

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

[PjJustin]

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

[wellerman]

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

[PjJustin]

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

[PjJustin]

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

[PjJustin]

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

[PjJustin]

@suloser 没老哥硬气。。。

[RandomJoke]

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

[qfdk]

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

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

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

[PuriNorm]

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

[Dylan89]

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

[defage]

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

[docx]

@PjJustin #19 很真实。哈哈哈哈

[wellerman]

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

[kakacoco]

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

[xiadengmaX1]

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

[PjJustin]

@kakacoco 这是真学到了

[QHKZ]

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

[siroleaf]

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

[unused]

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

[xuwuruoshui]

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

[winnerczwx]

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

[kcross]

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

[SuperTommy666]

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

[zeroSummer]

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

[LoNeZ]

安全和便利是相对的.

[GeruzoniAnsasu]

断章取义没有意义。

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


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

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

[Vegetable]

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

[min]

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

[Cruzz]

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

[brave6]

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

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

[DICK23]

refresh_token 机制真的毫无意义

[ugpu]

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

[youyouzi]

@PjJustin #22 你这个业务逻辑是对的啊，不就是这么干的？

[IvanLi127]

你们 CTO 这样说，我怎么感觉是他觉得目前设计过于复杂了？这和项目体量、部署方式有很大关系，这部分上下文没有到底谁该无奈还不好说

[iyaozhen]

工作前 3 年，我可能会支持你。

工作 10 年了，我感觉你还得练，能解释清楚很重要。即使是对牛弹琴，因为你有求于牛
说回问题本身，refresh_token 本来就挺傻的，而且每个人用的都不一样。access_token 过期了，用 refresh_token 去刷，就是因为 refresh_token 过期时间长一点，那怎么保障 refresh_token 安全呢。refresh_token 用过一次是否会失效，要再一次续 token 怎么办呢？是返回一个新的 refresh_token 还是重新登录？

[xue777hua]

cto 说的是对的。而且楼上很多人都提出了方案了。

刷新 token 和使用 token 刻意设计成了两个 token 因为本来就不是一个事。

你在登录的时候不需要考虑刷新，直接用即可。

过期了怎么办？当然是另一个任务 确保它不会过期。

[micean]

token 续期大部分场景也够啦，不过这 CTO 是老蒋吗？机枪位置也要管一下

[dog82]

CTO 不懂技术？？？

[doveyoung]

正常，拿多少钱干多少活，寻求他的认同不会加快你的工作效率。也许他是对的，不想对你解释；也许你是对的，你也不想对他解释。
工作而已，又不是结婚。easy easy

[clemente]

技术方案可以各有取舍，但如果沟通模式是 “我不要你觉得，我要我觉得”，长期确实很难协作。

[Mandelo]

单 Token + Redis 滑动过期可以解决大部分企业后台的需求。。。。

[XProxyAi]

对对对，老板英明神武，CTO 牛逼帅气，Token 就是永久能用的，你瞧瞧我这双腿，直接跪下去就完了，拿工资就行，技术，谁关心技术啊，能用就行，

[tangping]

让我想起来一个 输入 账号/密码登录 提示 密码错误，当前密码正确的登录账号应该为 XXX 😸

[cwliang]

bro 指鹿为马不懂吗，只要按时发工资老板想怎么凿都行，主打一个陪伴

[unco020511]

@PjJustin #22 这个没问题

[silence1corner]

我直接说，啊 对对～

[Plutooo]

太好了，上次见到技术讨论贴还是上次，这种技术活人感真的太好了，偏就偏吧 OP 不要纠偏了

[coolair]

你这算个啥，我领导连 API 是啥都不知道。

[hakuya7]

[zgsi]

单纯 jwt 无状态挺好的，
如果搭配上 refresh_token 就感觉怪怪的
感觉还是 jwt 搭配 Redis 好一点
但是这样就有状态了。。。
这不就变成 session 了吗

[kiripeng]

题外话，因为你在 CTO 上认为你没有被信任的资本，所以你需要准备好文本跟他对话，而不是各种意气用事，反正实在说不服就是照着做咯，给长文解释就行了。
对于内部的服务：
web 的
refresh_token 现阶段设计给服务端内部处理，给前端在 HttpOnly 塞入 seesion_id 就行了。
移动端的
refresh_token 和 access_token 给就行了。
pc 端的
看你方案，没啥研究。
对于外部对接服务：
refresh_token 和 access_token 给就行了。

[looppppp]

一般都是后端续的，特别是 jwt 很容易续期，前端给你刷新，一堆请求打出去你怎么拦住刷新完再请求（体验极差），之前我们后端也想这么做被我一说就懂了