在过去的几天里，我一直在阅读关于使用刷新和访问令牌的身份验证，但这是一件我找不到答案的事情。假设发送了一个过期的访问令牌。后端应该自动刷新它（如果提供了刷新令牌），还是应该只在刷新端点进行刷新？
例如，考虑以下两个身份验证流：
自动刷新
1.用户使用用户名和密码进行身份验证，API返回一个包含其数据的短期访问令牌和一个长期刷新令牌。
1.对于每个需要身份验证/授权的请求，用户将在请求标头上发送这两个令牌。
1.如果访问令牌过期，API将检查是否发送了有效的刷新令牌，它是否处于活动状态，以及它是否与访问令牌属于同一用户。如果一切正常，则它将签署新的访问令牌，并使用它更新响应头。
前端不必担心刷新令牌，但它仍然必须在每个请求之后查找响应头，以检查是否发送了新令牌。
手动刷新
1.用户使用用户名和密码进行身份验证，API返回一个包含其数据的短期访问令牌和一个长期刷新令牌。
1.对于需要身份验证/授权的每个请求，用户将发送其访问令牌。
1.当访问令牌过期时，用户将把他的刷新令牌发送到refresh/路由，API检查令牌是否有效，如果一切正常，则返回新的访问令牌。
在每次请求之后，客户端必须检查令牌是否过期，如果过期，则必须执行新的请求来刷新令牌。向服务器发出的请求越来越多，但另一方面，责任被更好地分离，因为auth路由只负责处理访问令牌，而刷新令牌处理位于另一个路由中。
我很难找到关于这个主题的资源，所以我不太确定哪个解决方案更好，甚至我描述的解决方案是否正确。如果我必须选择一个，我会选择自动刷新，因为这样做的请求更少，客户端可用性看起来更好，但正如我所说，我不是100%的，所以我做了这个线程。
应如何刷新访问令牌？
4条答案
按热度按时间c6ubokkw1#
在我看来，您缺少了一个角色，即授权服务器（AS）的角色：
刷新令牌始终是客户端的责任，只有访问令牌应该被发送到API。API的唯一OAuth任务是验证访问令牌并根据其内容进行授权。
有可能你有一个API正在做授权服务器的工作。我的目标是分离这些角色。如果它有助于我的Messages Blog Post有很多细节的消息在一个完整的UI和API解决方案。
brgchamk2#
我所知道的OAuth2协议的实现使用您在“手动刷新”下描述的流程。客户端必须自己关心刷新。
客户端可以在每次请求之前检查access_token是否仍然有效，也可以在请求由于令牌响应无效而失败之后进行刷新。
access_token是短期的，所以在每次请求时发送它，被窃听和滥用的风险是有限的。refresh_token是长期的，如果你在每次请求时发送refresh_token，攻击者获得它的机会就大得多。
如果你在每个请求中发送两个令牌，你就不需要区分这两种类型，你只需要使用一个长期令牌。
5jvtdoz23#
以下是使用自动刷新令牌循环方案的主要缺点：
假设客户端同时进行2个API调用（API A和API B）。在触发这两个API调用时，访问令牌已过期。这两个API调用携带相同的过期访问令牌和刷新令牌（假设此刷新令牌有效）。
让我们假设API A首先由服务器处理。根据自动刷新方案，服务器将检查API A的访问令牌，如果该令牌过期，服务器将检查刷新令牌，如果该刷新令牌通过验证（该刷新令牌也存在于数据库中），服务器将创建新访问令牌和新刷新令牌（API附带的刷新令牌将从数据库中删除，并使用此新刷新令牌进行更新）。这些新令牌将返回给客户端。
API B将遵循相同的流程。但是其刷新令牌将无效，因为在处理API A期间，数据库中的刷新令牌已被新令牌替换。API B的刷新令牌不在数据库中，因此此请求将失败。
如果同时调用多个API，自动刷新令牌循环方案将失败，因为在续订令牌时，第一个API请求将替换刷新令牌，其余API请求将带有数据库中不存在的刷新令牌！
pn9klfpd4#
我的经验是，OAuth2 access_token请求不喜欢额外的数据，这意味着您不能同时发送access_token和refresh_token，这将导致您所描述的手动刷新场景，这是唯一的选择