2017-02-22 109 views
1

我正在研究Oauth2,允许开发者授权其应用的用户使用我的服务。我发现了一些资源,说我的授权服务器应该在用户发送一个断言(我的情况是JWT)时返回一个访问令牌,但它不应该返回一个刷新令牌。我想知道返回刷新令牌有什么危害。开发人员可以通过调用一个Api来使刷新/访问令牌无效,这会使从特定JWT ID中授予的访问无效。Oauth2断言授权:为什么不刷新令牌?

+1

在[RFC7521](https://tools.ietf.org/html/rfc7521)中,刷新标记没有用,如[4.1节]中所述(https://tools.ietf.org/html /rfc7521#section-4.1):*客户可以通过请求使用相同断言的新的访问令牌来刷新过期的访问令牌,如果它仍然有效或者有新的断言。* –

+0

我不同意它没用。我正在考虑一个客户在一段时间不活动后醒来。该客户端必须向其应用服务器请求JWT,然后将该JWT换成访问令牌。这是2轮往返1次往返。也许这不是什么大不了的事情,但这里有一个不可忽略的性能影响。 – Mustack

+0

这是无用的,因为客户端可以通过发送相同的断言(如果没有过期)或创建新的断言来刷新它。由于它通常在客户端生成,因此这是一轮。 –

回答

1

该建议不正确。刷新令牌是可选的,并且可以在客户端颁发授权许可后由授权服务器酌情发布。见Oauth2 specification

1.5刷新令牌

刷新令牌用于获得访问令牌凭据。刷新 令牌由授权服务器发布给客户端,并且当当前访问令牌 变得无效或过期时获取新的访问令牌,或者获得具有相同或更窄范围的其他访问令牌012xx(访问令牌可能具有生命周期较短且权限较资源 拥有者授权更少)。 由 授权服务器决定是否可选发布刷新令牌。如果授权服务器发出刷新令牌,则在发出访问令牌(即图1中的 中的步骤(D))时包括该令牌。

+0

感谢您指出这一点。我重新检查了我阅读的来源,这让我对此产生了疑问。事实证明,这不仅仅是一种建议,而是一种观察。它说你通常不会在断言授权流程中提供刷新令牌。我想我只是想知道我是否在这里失去了劣势。 https://tools.ietf.org/html/rfc7521 – Mustack

+1

也许它是在谈论Oauth2.0中获得访问令牌的不同授权授予流程。 “授权代码授权”提供授权码,在第二步中您可以获得访问/刷新令牌。 “隐式授权”流程在一个步骤中提供访问令牌,并且不允许使用刷新令牌 – pedrofb