a1528zhang

@cheese app 内置了运行环境，这样分享代码的时候用 app 可以直接跑起来，不会有各种环境问题。
而且 app 内的编程体验也基本与 vscode 差不多

@Dlin 我理解 access token 用来访问的是授权方（比如 github 的 api ），我这里其实需要的是访问我们自己应用的后端，只需要一个登录成功的证明就行了

@fredweili 是的，其实就是 PKCE 了，但是 OAuth 签发的 Token 应该是无法主动失效的: https://auth0.com/docs/secure/tokens/revoke-tokens

不过我们重新获取 refresh Token 后，会让旧的 refresh Token 失效；由于我自己签算的 Token 是使用 ID Token + refresh Token, 也就达到了让前端 Token 失效的效果

@cat1879 我参考的参考他们的文档 https://auth0.com/docs/secure/tokens/refresh-tokens
1. refresh token 的时效性一般来说是比较长的，但是 id 和 access token 的时效会很短，但是如果我使用 refresh token rotate 机制的话 refresh token 的存在时间也会比较短
2. 我这边 token 只在第登录验证的时候会使用 appid 和 seceret 交互，但是之后可以使用 refresh token 进行刷新，就不需要 secret 了
3. 确实理论上我应该把 token 全部放在后端，然后我的后端再做一个单独的授权 token 给我的前端。但是这个行为本质上是给前端一个唯一的身份证明，所以我选择吧 id token 加密后生成一个新的 token 来承担这个功能，这样我也不用做签算机制了，少点工作。

@patrickyoung 感谢 我再去翻一下

@patrickyoung 是的，我把 ID Token 加密后作为身份认证，来访问我们自己的后端 api ，并没有访问授权方（比如 github ）的 api 。所以应该不涉及 api 的调用，如果 我不用 ID Token 那么我也要自己生成一个 Token 给用户来证明他已经登录了。

所以当这个 token 被盗取了后，攻击者和用户都可以使用同一个 token 来调用我们后端服务 api ，然后我们的 api 中包含一个刷新 token 的 api ，所以攻击者和用户就都能不断获取新的 token 来保持永久登录。

@anonydmer 是的，我理解 access token 是用于访问我们申请权限的服务的 api ，比如我们接入的 github 的账号，然后我们拿到的 access token 也仅用于访问 github 的 api 。

ID Token 我是用作一个登录凭证，证明这个用户登录成功了，那么他可以调用我们服务端的 api 而不是 github 的 api 。所以我理解 ID Token 我应该没有用于请求，而是只用于身份证明。

那么这个身份证明被盗用后，我们后端是否有手段可以让这个特定的身份证明失效呢？

@iyiluo 嗯现在看来设备 ip 绑定是比较保险的做法，以后会做。因为我们做了 token 刷新的机制所以定期失效的手段没用了

@cheng6563 这个我考虑过，但是如果被窃的用户长时间不登录就没法挤掉