【问题标题】:Should OAuth 2.0 be used for Authentication Timeouts?OAuth 2.0 是否应该用于身份验证超时?
【发布时间】:2019-04-08 20:50:24
【问题描述】:

移动应用程序的开发人员正在使用 OAuth 2.0 令牌的超时期限来检查应用程序何时必须重新向服务器进行身份验证。

这与我对正确使用 OAuth 2.0 令牌的理解相冲突,尽管我不确定自己是否正确。

我的理解:

OAuth 不是关于身份验证,而是关于授权,例如该设备可以代表用户访问服务器上的某些资源吗?身份验证在逻辑上先于授权,是关于确认用户就是他们所说的身份。

因此,用户提供凭据(用户名和密码)并且服务器验证是的,该用户是 Bob。

Bob 已登录的应用程序希望访问 Bob 已通过身份验证的服务器上的某些资源,例如来自 API 的数据。所以应用程序请求一个 OAuth 令牌并被授予,它的属性之一是它存在多长时间。应用程序和服务器交换密钥,应用程序和服务器之间的数据使用密钥加密。

读取明文通信的入侵者将无法在没有密钥的情况下对其进行解码。但是,如果入侵者能够获得他们将能够获得的密钥。

这就是 OAuth 令牌生命周期结束的地方。我们不想永远使用相同的 OAuth 令牌(密钥),因为如果入侵者能够获得该令牌,他们就可以永远破坏我们的通信。但是,如果我们每 x 小时刷新一次令牌,那么它们只能在 x 小时(比如说 2 小时)内使信息失效。

我认为 OAuth 令牌到期时间不应与用户保持身份验证的时间长短相关。这完全取决于开发人员。在我们的例子中,如果用户有一些设备安全性(例如密码),那么我们可以让他们长时间保持身份验证(例如几个月)。如果他们没有设备安全性,那么我想强制他们在一段合理的不活动时间(可能是 24 小时)后重新进行身份验证。

这是否正确,如果不是,是什么部分。

提前致谢。

布莱恩

【问题讨论】:

    标签: authentication oauth-2.0 authorization


    【解决方案1】:

    您对 OAuth 2.0 的理解是正确的。协议以非常抽象的方式定义了一种获取令牌的方法,客户端可以使用令牌与受保护的端点进行通信。

    RFC6749 要求在与授权服务器通信(获取令牌)以及针对 API/受保护端点使用 TLS 时(RFC6750 中定义的承载令牌使用)。这可以保护令牌免受传输中的攻击。

    建议 OAuth 访问令牌的生命周期较短。这是为了避免客户端可以进行的令牌窃取和令牌滥用。您可以从RFC6819 阅读有关最佳实践的更多信息。访问令牌生命周期细节可以从here 阅读。

    现在关于选择正确的生命周期。正如您已经发现的那样,使用刷新令牌是更新访问令牌的理想方法,而不是拥有持久的访问令牌。例如,刷新令牌可以在几天内有效,而访问令牌仅在几个小时内有效。

    但请注意以下事项,

    +您的应用程序是否可以获得并保护刷新令牌

    例如,SPA 无法获取刷新令牌,因为它无法长时间存储它。在这种情况下,您需要寻找替代机制来更新访问令牌。

    + 访问令牌是否用于外部域

    对外部 API 使用访问令牌会增加威胁向量。例如,如果您有一个封闭的系统(客户端和后端在一个域中),那么您可能会考虑增加访问令牌的生命周期。但不是像 24 小时这样的长时间。!

    +单点登录 (SSO)

    您可以借助授权服务器在浏览器上维护 SSO 行为,而不是使用持久的访问令牌。这类似于您在现代登录对话框中观察到的“记住我”。登录后,浏览器会保留一个 cookie,该 cookie 会持续一段时间(例如:一周)。下次您使用 OAuth 令牌获取流程时,您的授权服务器会检测到此登录状态,因此会跳过登录对话框。当然,这种方法必须根据确切的安全/策略要求来决定。

    总之,使用寿命较短的访问令牌。使用刷新令牌是令牌更新的理想方法。但根据情况,您也可以选择替代方案。

    【讨论】:

      猜你喜欢
      • 2012-11-08
      • 2014-08-26
      • 2011-03-18
      • 2023-03-07
      • 2014-12-27
      • 2012-05-29
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多