我有一个程序,与YouTube直播API集成。它在计时器上运行,所以对我来说,每50分钟用刷新令牌获取一个新的访问令牌相对容易。我的问题是,为什么?
当我通过YouTube认证时,它给了我一个刷新令牌。然后,我大约每小时使用这个刷新令牌来获得一个新的访问令牌。如果我有刷新令牌,我总是可以使用它来获得一个新的访问令牌,因为它永远不会过期。因此,我不认为这比从一开始就给我一个访问令牌而不打扰整个刷新令牌系统更安全。
我有一个程序,与YouTube直播API集成。它在计时器上运行,所以对我来说,每50分钟用刷新令牌获取一个新的访问令牌相对容易。我的问题是,为什么?
当我通过YouTube认证时,它给了我一个刷新令牌。然后,我大约每小时使用这个刷新令牌来获得一个新的访问令牌。如果我有刷新令牌,我总是可以使用它来获得一个新的访问令牌,因为它永远不会过期。因此,我不认为这比从一开始就给我一个访问令牌而不打扰整个刷新令牌系统更安全。
当前回答
使用短时间的访问令牌和长时间的刷新令牌至少有3个相关的原因。
不记名的令牌
从最初的问题:
如果我有刷新令牌,我总是可以使用它来获得一个新的访问令牌,因为它永远不会过期。
虽然您可能总是能够使用刷新令牌获得新的访问令牌,但攻击者通常不能。这是因为你对刷新令牌的使用与你作为客户端的身份证明相结合,例如通过提供你的client_secret。访问令牌不需要这样的证明,因为访问令牌是持名令牌,也就是说,简单地呈现它们就足够了。
如果访问令牌是短期的,则在一定程度上减轻了这种访问令牌的无限功能。
攻击面
访问令牌与(可能有许多)资源服务器交换,这增加了泄漏的机会。刷新令牌只与授权服务器交换。
同样,访问令牌的短寿命至少是某种程度上的缓解。
撤销
将访问令牌实现为有签名的jwt是可能的(也是常见的)。在这种情况下,任何服务器(知道签名方的公钥,通常位于某个众所周知的位置)都可以独立地验证访问令牌的正确性。这可以很好地实现体系结构的解耦,因为资源服务器不必向授权服务器询问授权。
这种设置的缺点是不能撤销这样的令牌(不需要像撤销授权服务器的公钥那样激烈的操作)。
通过使访问令牌的生命周期很短,可以简单地允许它们运行完,而不是显式地撤销。
其他回答
这是一次很好的学习经历,了解了令牌、刷新令牌和缓存它。然而,(我很好奇,我在这里不给出任何建议)我们可以使用用户登录后返回的代码,当使用微软身份平台时。我们是否可以只存储CodeIdToken,并在需要时使用它来获取新的访问令牌?因为我在想,我们用它来获得访问令牌,那么我们应该每次都用来重新生成访问令牌吗?
...
ResponseType = OpenIdConnectResponseType.CodeIdToken,
...
and
private async Task OnAuthorizationCodeReceived(AuthorizationCodeReceivedNotification context)
{
IConfidentialClientApplication clientApp = MsalAppBuilder.BuildConfidentialClientApplication();
AuthenticationResult result = await clientApp.AcquireTokenByAuthorizationCode(new[] { "User.Read" }, context.Code)
.ExecuteAsync();
}
下面是OAuth 2.0文档中的信息。
刷新令牌用于在当前访问令牌失效或过期时获取新的访问令牌,或获取具有相同或更窄范围的其他访问令牌(访问令牌的生命周期可能比资源所有者授权的权限更短)。
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
(A)客户端通过认证请求访问令牌 授权服务器和呈现授权授予。
(B)授权服务器对客户端进行身份验证和验证 授权授予,如果有效,则发出访问令牌 和一个刷新令牌。
(C)客户端向资源发出受保护资源请求 通过显示访问令牌来访问服务器。
(D)资源服务器验证访问令牌,如果有效, 为请求服务。
(E)步骤(C)和(D)重复直到访问令牌过期。如果 客户端知道访问令牌过期,则跳过步骤(G); 否则,它将发出另一个受保护资源请求。
(F)由于访问令牌无效,资源服务器返回 无效的令牌错误。
(G)客户端通过验证请求一个新的访问令牌 授权服务器和显示刷新令牌。的 客户端身份验证需求取决于客户端类型 以及授权服务器策略。
(H)授权服务器对客户端进行身份验证和验证 刷新令牌,如果有效,发出一个新的访问令牌(并且, 可选的,一个新的刷新令牌)。
access_token使用得更频繁,撤消的能力不是很重要,因为它们的生命周期很短。
refresh_token使用的频率较低,撤消的能力至关重要,因为它们可以用来生成新的access_token。
验证已签名令牌的成本较低,但撤销令牌很困难。
验证存储在数据库中的令牌的成本很高,但很容易撤销。
因此,签名密钥可以用作access_token来提高性能。
Db存储的键可以作为refresh_token使用,以便于撤销它们。
如果没有refresh_token,就很难找到一种提供低成本验证和简单撤销能力的机制。因此refresh_token的存在是由于性能原因。
基本上,刷新令牌用于获取新的访问令牌。
为了清楚地区分这两个令牌并避免混淆,以下是OAuth 2.0授权框架中给出的它们的功能:
Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server. Refresh Tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope.
现在,为了回答你的问题,为什么你仍然被发出一个刷新令牌,而不仅仅是保护一个访问令牌,互联网工程任务组在刷新令牌中提供的主要原因是:
出于安全原因,refresh_token只与授权服务器交换,而access_token则与资源服务器交换。这降低了在“一个访问令牌可以持续一小时,有一个刷新令牌可以持续一年或直到被撤销”和“一个访问令牌可以持续到被撤销而没有刷新令牌”之间存在的长期access_token泄漏的风险。
有关OAuth 2.0流程的更详细和完整的信息,请尝试阅读以下参考资料:
OAuth 2.0流程:服务器端web应用程序 IETF (Internet Engineering Task Force)发布的OAuth 2.0授权框架 为什么OAuth v2同时拥有访问和刷新令牌?
refresh_token模式使OAuth服务器处于控制状态,因此当发生不好的事情(如access_token和refresh_token泄露)时,服务器可以进行干预。
e.g.
如果access_token和refresh_token落入黑客手中,access_token将很快过期,黑客可能会尝试刷新令牌,但服务器现在有能力/控制不再发出access_token(考虑到服务器获得了泄漏信息)。