OAuth 认证机制下，如果 Token 被窃取了是否意味了账号被盗？有办法减轻影响吗？

[a1528zhang]

我是一个刚接触 OAuth 的新手，最近刚接入了 auth0 的身份验证。

我们的产品是一个 web app ，然后后端作为 auth0 的客户端，保存了 auth0 返回的 access Token, refresh Token ， 然后将 ID Token 加密后放到前端，作为用户的登录凭证。用户调用我们的后端 api 的时候直接验证一下 ID Token 是不是合法，然后就直接做用户操作了。

然后我们为了用户体验使用了 refresh Token 来刷新用户的 ID Token ，当 ID Token 过期的时候就调用一下后端的 api ，后端再到 auth0 去请求新的 token ，然后更新 access Token, refresh Token ，再把新的 ID Token 返回给用户。

我的疑问是，当用户的 ID Token 被获取了，在这套机制下就等于是账号全部失窃了，因为攻击者可以利用 refresh Token 不断刷新有效期。所以要如何解决这个问题？我的这个实现流程是否有问题？

希望有经验的大佬解答一下，感激不尽

[a1528zhang]

@patrickyoung 感谢 我再去翻一下

[cat1879]

1 、refresh token 有时效性，一般都是两小时失效；
2 、token 要用 app id 和 app secret 来换；
3 、token 应该要结合单个用户再获取一个认证，用这个认证给个用户做授权；
所以理论上 id secret token 这三个都在后台跑，token 在不同站点间交互可能会有泄露；用户认证授权有可能泄露但只对单个用户； 按你的描述我感觉你是不是少了一级，你是直接把 token 当公共参数丢给所有用户作为授权了

[a1528zhang]

@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 来承担这个功能，这样我也不用做签算机制了，少点工作。

[fredweili]

你说的这个算法类似 PKCE
token 可以在 server 端 invalidate 的，看 server 端的检测机制

[a1528zhang]

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

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

[Dlin]

access Token 就是拿来认证的，干嘛还要搞个 ID Token 。你这个问题我曾经也想过，任何认证方式在泄露 token 后都存在用户信息的不安全。你的想法是持票人的实现办法，可以做到单设备登录，用户可以感知被挤了下去了，算是加强了一些。

[Dlin]

refrash_token 只能使用一次，刷新后返回新的 refrashToken 。

[a1528zhang]

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