`refresh token`是否会过期,如果是的话?

rab*_*tco 17 oauth-2.0 podio

我已经阅读了PODIO文档.我特别考虑了以下关于使用以下内容的声明refresh_token:

此请求返回与上面相同的数据,您可以反复继续执行此操作,以保持应用程序的身份验证,而无需要求用户重新进行身份验证.

这是否意味着refresh_token它将无限期有效或过期:

  1. 发行后X天; 要么
  2. 最后一次使用它以获得新的X天后 access_token

任何帮助将非常感激.TIA!


编辑:请参阅此PODIO线程,它提出相同的问题,但似乎没有给出关于Oauth2.0协议的PODIO实现的任何结论性答案.

Sur*_*raj 13

你的问题的答案

这是否意味着refresh_token将无限期有效或者它是否会过期?

可以从oauth 2.0规范的1.5节10.4 得出结论.

1.5节介绍refresh_token表示:

刷新令牌由授权服务器发布给客户端,用于在当前访问令牌失效或过期时获取新的访问令牌,或者获取具有相同或更窄范围的其他访问令牌(访问令牌可能具有更短的生命周期和权限少于资源所有者授权的权限)

第10.4节refresh_token的安全注意事项指出:

只要可以验证客户端身份,授权服务器就必须验证刷新令牌和客户端身份之间的绑定.当无法进行客户端身份验证时,授权服务器应该部署其他方法来检测刷新令牌滥用.

例如,授权服务器可以采用刷新令牌
轮换,其中每个访问
令牌刷新响应发出新的刷新令牌.先前的刷新令牌无效,但由授权服务器保留.如果刷新令牌被
泄露并随后被攻击者和
合法客户端使用,则其中一个将呈现无效的刷新
令牌,这将通知授权服务器该违规.

可以得出结论,如果refresh_token能够验证a refresh_token和发给它的客户之间的绑定,那么access_token 可以用来获得多个refresh_token并且永不过期.否则授权服务器将使旧的无效refresh_tokenrefresh_token使用每个访问令牌刷新响应生成新的.

  • 我并没有从上面得出同样的结论。我看到很多 OAuth 实现都带有过期的刷新令牌,我怀疑它们都违反了合同 (2认同)

Jan*_*yka 7

TL; DR

刷新令牌最终过期或失效,你应该准备好了。

两种场景:

  1. 面向用户的服务(例如:授权授予流程)- 可以忽略该问题,因为人们擅长将其关闭再打开,也就是刷新页面 :-)

  2. 服务器端长时间运行的服务(例如:客户端凭据流) - 您应该为访问或刷新令牌都不起作用的情况做好准备,并从头开始重新启动身份验证。

现实生活

刷新令牌可能有也可能没有到期时间,这取决于您的提供者,它们永远不会过期,只要它们是最近的使用过,几个月或几小时即可。依赖于您将收到带有刷新访问令牌的新刷新令牌这一事实可能会很棘手。

超时并不是令牌失效的唯一方式。考虑oauth0中描述的以下场景:

虽然刷新令牌通常是长期存在的,但授权服务器可以使它们无效。刷新令牌可能不再有效的一些原因包括:

  • 授权服务器已撤销刷新令牌
  • 用户已撤销其授权许可
  • 刷新令牌已过期
  • 资源的身份验证策略已更改(例如,最初资源仅使用用户名和密码,但现在需要 MFA)

此外,令牌(访问、刷新)可以存储在身份验证提供程序服务的非持久存储中,因此如果服务重新启动(崩溃、更新),您的令牌可能会消失。

结论

如果您正在编写需要可靠的长时间运行的服务,请不要依赖于能够通过刷新令牌永远刷新授予的身份验证。


Xav*_*gea 5

刷新令牌将在创建后 X 天(或几小时)过期。根据您的安全要求,此到期时间为 1 个月或 1 小时。

您必须在做出决定时考虑功能和安全性等某些方面。

  • 如果您决定优先考虑安全性,那么短暂的到期时间可能会使您的应用程序对用户产生厌烦感。
  • 如果您决定优先考虑功能,您的应用程序可能更容易受到攻击。

  • @rabbitco 存储在数据库中的refresh_token将有一个在创建时决定的到期日期。过期后,refresh_token 将毫无用处。因此,用户必须再次登录应用程序才能创建新应用程序。 (2认同)