【问题标题】:Refresh access token before it expires using refresh token使用刷新令牌在访问令牌过期之前刷新它
【发布时间】:2021-11-16 02:01:12
【问题描述】:

我正在开发一个使用 OAuth - 基于令牌的身份验证的应用程序。

考虑到我们有访问和刷新令牌,这就是流程的样子。

  1. API 调用 -> 拦截器附加访问令牌 -> api 返回 200
  2. API 调用 -> 拦截器附加过期的访问令牌 -> api 返回 401 -> 拦截器使用刷新令牌刷新令牌 -> 拦截器重试相同的请求 -> 返回 200
  3. API 调用 -> 拦截器附加过期的访问令牌 -> api 返回 401 -> 拦截器使用刷新令牌刷新令牌(刷新令牌 也过期了)->提示客人登录->客人登录-> 重试请求

这一切都很好 - 我正在考虑对其进行一些优化,即我不想调用 api 并等待 401 返回。 而是事先检查令牌是否过期,获取新的访问令牌,然后使用有效令牌调用 API。

这种使用 android 系统时间计算令牌到期的方法可能有效 - 但有时当用户更改 android 时间时可能会被误用。

想知道是否有更好的解决方案来避免基于android系统时间的时间到期问题。

【问题讨论】:

    标签: android oauth-2.0 jwt access-token systemtime


    【解决方案1】:

    即使您在代码中添加了这样的检查,您仍然需要您在问题中提出的流程(因此捕获 401 并相应地刷新令牌)。这是因为,正如您所注意到的,客户端设备上的时间设置可以更改,或者客户端和服务器之间可能存在轻微的时钟偏差(因此不会故意篡改时间设置)。

    仅当您有权访问访问令牌和刷新令牌的到期时间时,在 API 调用之前检查到期的方法才有效。因此,您要么收到该信息以及令牌并将其持久化,要么使用 JWT 并且您可以轻松检查过期。

    就个人而言,我不会添加这样的检查,除非有一些强有力的论据(例如,您知道您的应用将主要用于连接速度较慢的远程位置,并且您希望将流量限制在最低限度等。 )。您提供的流程是一个常见的流程,并且运行良好。

    【讨论】:

    • 我在同一页上。不使用系统时间 - 但依靠 401 触发刷新。问题是 - 使用无效/过期令牌击中服务器。我想了解,其他人是如何处理它的。遇到这个库github.com/openid/AppAuth-Android/blob/…,看起来它使用系统时间。不知道他们是如何避免的,以防系统时间发生变化。
    • 可能是库不处理。如果需要,可能需要开发人员正确捕获 401 并刷新令牌。
    猜你喜欢
    • 2019-04-07
    • 2020-06-12
    • 2019-06-29
    • 1970-01-01
    • 2018-06-05
    • 2020-07-12
    • 2022-10-31
    • 2021-12-19
    • 2019-05-31
    相关资源
    最近更新 更多