请问 OAuth 中的 access_token 为什么需要过期

[cc959798]

为什么需要设置国企 refresh_token 来刷新 access_token，有些人说是因为 Access_token 会过期，refresh_token 也会过期，为什么不设计成 access_token 和 refresh_token 一样长的过期时间，然后 refresh_token 就不需要了，反正 refresh_token 也会过期

[chinvo]

feng huang 的 V2EX iOS app 里面误点感谢突然不能取消感谢好尴尬……

[chinvo]

@march1993 #20 所以 access token 有效期是短暂的，即使泄露不会造成太大危害，但是如果按你的思路设置为长期，就是很危险的了，尤其是有一些 authentication provider 不支持 revoke access token 的情况下

[march1993]

@chinvo 不啊，按照我的思路，我的 token 是独立的，也就是这个 token 能做的事情也是有限的，所以危害是可以控制的。在被污染的 provider 被发现之前，它也可以一直请求更新 token，所以我觉得这个危险可能更严重。

[march1993]

@chinvo 即便如此，像我们这种下游开发者也只能跟着 access_token 走了

[chinvo]

@march1993 #20 抱歉认错了，误认为你是楼主……

access token 被泄漏的时候的安全性保障，来自于短期有效。

另外为了避免 public 的 client （单纯 agent 的 client，包括网页、手机 app ）所取得的 access token 泄漏造成麻烦，还引入了 PKCE

[chinvo]

@march1993 #23 resource provider 并不能更新 token，他只能使用 token 去进行认证或者访问 api，只有 client 能更新 token

[march1993]

@chinvo 我理解的短时对于入侵者来说用 access_token 配合预先编写的程序可以干一堆事情了，所以可能我理解上有偏差

[chinvo]

@march1993 #27 resource provider 的接入一般是受 authentication provider 管理方的严格限制的，所以这个角度不容易泄漏。

大部分只在服务器上调用 RP 接口的 client 也不会泄漏 token。

那么就只剩下 agent 了，而 agent 是不允许持有 client secret 和 refresh token 的。

此时 access token 若泄漏，只会造成短时间的风险（一般是 3600 秒），虽然可以做一堆事，但远比直接泄漏用户密码或者长期令牌要安全的多。

更严格的策略要求 agent 也不可以持有 access token，必须通过后端服务器与 IdP/RP 交互。

在最严格策略下，可能的泄漏风险是换取 access token 之前，authentication provider 返回的 code，引入 PKCE 对 agent 进行 challenge，code 与 PKCE 的 code_verifier 绑定，只有此 agent 的后端服务器可以用 client_secret, code_verifier 和 code 换到 access token。

[SingeeKing]

假设 access token 一天过期一次

那么 refresh token 换取 access token 每 24h 只要一次就好了，也就是说每天只有这一次的机会会泄漏 refresh token
而 access token 则会在每一次调用中都可能泄漏，泄漏几率远大于 refresh token


---------------

其实问题来了，如果服务器是 https 的话，那么如果不考虑中间人应该都不会泄漏，而如果被中间人了那么很大几率 refresh token 也保不住（毕竟被中间人攻击的话手机或电脑应该已经被安装了第三方根证书）

[chinvo]

@march1993 另外你 #24 说的没错，通常情况下，token 泄漏，client 的开发者是除用户之外最大的受害者。

所以理论上 client 的开发者有权利和义务选择最严格的流程并且完整实践 OAuth 2.0/OpenId Connect 所有对于安全性的要求和建议。

而对于敏感数据的提供方，作为 RP 应当要求 client 和 IdP 使用严格的 token 交换机制。
作为 IdP，因其本身不提供敏感数据（ OAuth 中只作为用户身份认证令牌的提供方，OpenId Connect 中还要提供一个 Userinfo Endpoint ），则应当为 RP 和 client 的安全性考虑，为他们实作标准中提出的安全机制。

[chinvo]

@SingeeKing #29 按照 IETF 和 OpenId 的要求，refresh token 和 client secret 是不可以放在 agent 上的，也就是说，其实目前大部分将 refresh token 和 client secret 保存在用户手机或者其他设备的 agent 是不合规且有隐患的。

[SingeeKing]

@chinvo #31 What。。Refresh token 不放在客户端怎么刷新。。

[chinvo]

@SingeeKing #32 由客户端的服务器刷新。

如果你真的在客户端能成功刷新 access token，那么你的 client secret 已经至少暴漏给用户了

[choury]

@SingeeKing #29 access token 可以放在 url 里面的，能拿到这个的可能太多了，而 refresh token 只存在自己服务器上，除了和 auth server 交互之外不会被传送
说白了这套流程防的是不怀好意的第三方，并不是用来防开发者的

[choury]

@SingeeKing #32 放在客户端，那客户就可以伪造你了……

[ooh]

cookie 为什么需要过期？

[q397064399]

本身并没有什么卵用，

通信层面上保证安全的是 https 跟非对称加密协议，
客户端层面上是开发者 保证内存不被恶意 dump，token 不被恶意获取

客户端如果保护不了 token 那也同样保护不了 refresh_token
非对称加密要是 证书被恶意篡改 遭受中间人攻击 同样是被脱了裤子，
你捂住了下面，就捂不住上面，也是没有什么卵用

另外 md5 挑战认证，了解一下？

[chinvo]

@q397064399 #37 所以 refresh token 是禁止放在 agent 的

[q397064399]

@chinvo #38

不解，如果 refresh_token 不放在客户端，客户端如何刷新 token，
需要借助服务器来刷新么？ 那服务器 与 客户端 怎么确认 认证身份？

[chinvo]

@q397064399 对的，要用服务器来刷新，客户端和服务器之间没有具体规定，你可以用 access token （由 IdP 颁发而非自行颁发）、cookie、session、或者自行颁发 access token