回来看了一下，发现我表述有点乱，导致跑题了，总结几点吧

1. 还是不要试图用 JWT 来颁发长期令牌了，安全问题 JWT 这种无状态的 token 本来就没法解决。

2. 长期甚至永久令牌本身就有其使用场景，没必要考虑长期令牌的不安全这个问题，真要说的话长期密码更不安全，但我们不也一直在用吗，作为服务提供商，应该是要考虑如何保证长期令牌的安全。

3. 本贴讨论的主要是自动化身份认证，所以需要人为介入的都不在讨论范围（比如要登录，要用户输入密码，要用户确认等）

4. 本帖讨论的为身份认证，上面 nothingistrue 把身份认证拆分成了登录认证和后续认证，不是我想问的问题，参考 API Token （就是一步身份认证，没有再分两步了）

5. 感觉大家一直在说 JWT ，但其实我一直就不想用 JWT （参考第一点）
卧铺专票这种就和 JWT 一样，只能用于短期，就不说了，参考第 1 点。

6. 敏感操作也可以不用讨论了，参考第三点，判断操作敏感度这个属于 AuthZ 了

7. nothingistrue 说怎么存储不重要，是因为你把这玩意理解成 authz 了，其实他都还没到 authz ，认证合法性就是 authn ，都不用考虑这个 token 有什么权限，怎么存储关系的是 authn 过程的索引效率问题。（然后 github 令牌丢了可不只是丢脸这么简单，不要只考虑 push 的场景）

8. 然后反驳一下自己的观点：key 用 json 存用户信息和加密 token 没什么意义，效率还低，直接 key 存明文 token ，value 用 json 存用户信息即可（不是 JWT ）。加密 token 只能防止数据库泄漏导致 token 明文泄漏，但权限依然会泄漏，token 明文泄漏对别人来说没有意义，和密码不同。

git reflog


一般我就是按照公司或主站去简单分类，没进分类的会不定时删

我一般会有搞自动策略，然后分文件夹，有时候会想看看各家公司的广告，整理起来会比较方便查看，一般不是非常重复的邮件我不会删

其实下班用最多的是 bash ，hhhh ，一直在搞部署，没怎么写代码

会
上班 go ，下班 go > c++ > html/js/css > c

所以，拿 typora 和 vscode 比，感觉完全没有意义。面向的需求都不一样，况且所说的那几个优势，其实 vscode 也能实现。

所以 typora 最大的优势就是所见即所得，同时 vscode 最大的优势就是纯文本编辑（好像 vscode 也有插件能支持所见即所得）。这完全是需求和个人的编码理念所决定的

我觉得 typora 和 markdown 完全就是两个东西，我认为 typora 非常不符合 markdown 的哲学

在我的观念里，typora 一直就不是个 markdown 编辑器，只是他刚好存储成了 markdown 格式而已。（用 typora 大部分是贪图 markdown 的轻量，又想要像 word 一样控制排版，直接看到最终效果，但这种需求确实普遍存在，这就是 typora 如此火热的原因）

然后回到为什么 typora 不符合 markdown 哲学（或者最初的哲学）的讨论：

#### 1 纯文本的可读性

我们去各种百科里面看 markdown 的介绍，基本上都会说最重要的是__纯文本的可读性__，这种所见即所得的理念，就是放弃了纯文本可读性的，因为你的纯文本可以写的非常的凌乱，反正最终效果是整齐的就好。

我这几年看过的，大部分用 typora 写出来的 md 文件，纯文本的可读性都非常差，有的只是有大量的空行和空格，这种还好，有的会内嵌大量的 html 语法，换行全靠 `<br/>`，还有一堆的特殊字符，一堆的 `&nbsp`，这种拿普通文本编辑器打开就跟一坨屎一样。

还有一点是很多其他编辑器一样会遇到的问题，就是表格不进行格式化，因为现在大部分 md 编辑器都有实时渲染的功能了，很多人就不注重纯文本格式下表格的问题，typora 我记得会自动格式化的，感觉就还好，有些不会自动格式化的，纯文本读起来就很吃力。

#### 2 沉浸式写作

同时 markdown 所强调的沉浸式写作，希望用户不要去关注排版，专注于写作本身。
在实时渲染的模式下，你就必须去关注排版问题，感觉与 md 哲学背道而驰，不过 typora 也有纯文本编辑模式，但用 typora 的应该很少人用这个功能。

还有一点，就是修改困难，当一个文本被渲染成功后，就会在显示上丢失格式编码的信息，想要修改很多时候得用到鼠标，不过最新的版本好像好了很多。

@wangxiaoaer

IAM 系统：OpenIAM 、KeyCloak

还可以了解一些开源 Devops ，这些系统一般把 IAM 集成到自己的系统，如果有合适的也可以拿来用

如果是企业内，除非只要很简单的逻辑，我建议，网关用开源的方案，IAM 自己实现，因为 IAM 系统看起来很通用，实际上非常的业务相关，很多时候企业内都会有那么几个比较特殊的需求，用开源的无法实现（当然如果是小功能也可以选择用开源，然后回馈社区）

说到这里，我就想起来一个比较经典的密码学问题。

安全的密码要求人在不同系统使用不同的密码，并且要有高复杂度，这本是好事，但由于系统太多，密码太复杂，没法记清楚，于是大多数用于选择将密码写在便利贴上，以方便登录时候能快速获取密码。然后便利贴被盗了。

@IvanLi127 是的，长期 token 一定更不安全，但是确实有使用场景，比如 git 上面我想要每次发版本时候自动获取项目的一些信息，就得调用 api ，如果只有短期 token ，用户很有可能会把账号密码直接存储下来自动获取 token ，这就不是我们想看到的结果了。

要相对安全点就是得用 api token ，可以申请一个范围很小的，比如只能读项目信息的 token ，相对来说，泄漏后造成的损失也就比较小了。方便和安全之中总要取得某些平衡。

@SSang 嗯，不如说，是用了 json 格式的 token ，实际上不用来做 JWT 的无状态校验。

@Chad0000

嗯，感觉纠结半天还是用回了 JWT 。

上次有个有个帖子有人说 JWT 存有状态就是 ** 我还给他点了个赞。（笑哭）

@Chad0000

我比较核心的使用场景是，用于 CI 中调用，或用于命令行脚本调用。这种场景，比如 CI 这种无交互的就不能用户登录，必须提前把 token 配进去，然后他的有效期一般都是以年为单位的，甚至有些低权限的是永久有效期。

这种场景感觉用 refresh token 就有点奇怪，一是因为我用命令行实际上不好存 access_token ，如果是 CI 里面，存缓存也有点奇怪。二是定时任务往往超过 access_token 的有效期，比如每个月只执行一次的任务，相当于每次我其实都是拿 refresh_token 去请求，和 access_token 就没关系了。

@3dwelcome

> 你是怕 token 时间太长泄露吗？我个人觉得问题不大，后台都是可以控制的。

不是，我是觉得 refresh_token + access_token 的使用场景，一般适用于相对短期的认证，比如比较主流的 oauth 、oidc 就是用户先通过用户密码登录，然后服务端返回 refresh_token 和 access_token ，当 access_token 过期时，拿 refresh_token 刷新。和 git 上面的 用户令牌 是由用户申请，之后直接拿 token 访问 api 不太相同。

> 类似 B 站的 cookie, 接近一年前的我都还在用，也没啥问题。

这种隐私性不高的页面一般确实长时间持有 token 也问题不大，但是比较敏感的，比如 阿里云的后台，AWS 的后台界面，这种，他们就不会长时间持有 token （没记错的话他们两个的有效期都是 18 小时）

@3dwelcome 那这种就是数据库存 token 的 hash 值了吗，比如像 gitlab 还有 personal_access_token 他可以创建好多个，那登录时候，如果有加随机盐，就得一个一个地取盐然后 hash 校验，这个索引效率就很低了。

@Chad0000 确实，OAuth 就是这么设计的，但实际上这个 RefreshToken 的有效期也不会很长，比如默认是 30 天，像 gitlab 、github 的 token 往往有 90 天，180 天，甚至是永久有效期。所以感觉实际设计时候不太能用这种方式。

然后其实我想讨论的就是这个 Refresh Token 要怎么存，要不要带用户信息，如果不带如何索引等。这个比较纠结，其实如果能想明白这个，我就不纠结用不用 Refresh Token 了

你先把 F J 和符号键装上就知道了吧