PROSAGA码农传奇-区块链扩展技术-为什么OAuth v2同时具有访问权限和刷新令牌？

11 条回复

0#
回复此人
咿呀哟 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 要清除一些困惑，你必须要了解它的作用 <a href="https://salesforce.stackexchange.com/questions/14009/whats-the-benefit-of-the-client-secret-in-oauth2"> 客户秘密 </A> 和 用户密码 ，这是非常不同的。 该 客户 是一个应用程序/网站/程序/ ...，由服务器支持，想要 认证 一个 用户 通过使用第三方身份验证服务。客户端密钥是此客户端和身份验证服务器都知道的（随机）字符串。使用此秘密，客户端可以通过身份验证服务器识别自己，接收 授权 请求访问令牌。 要获取初始访问令牌和刷新令牌，需要的是： <UL> <LI> 用户ID </LI> <LI> 用户密码 </LI> <LI> 客户端ID </LI> <LI> 客户的秘密 </LI> </UL> 但要获得刷新的访问令牌 客户 使用以下信息： <UL> <LI> 客户端ID </LI> <LI> 客户的秘密 </LI> <LI> 刷新令牌 </LI> </UL> 这清楚地表明了不同之处：刷新时，客户端通过使用其客户端密钥接收刷新访问令牌的授权，因此可以使用刷新令牌重新验证用户 代替 用户ID +密码。这有效地防止用户必须重新输入他/她的密码。 这也表明丢失刷新令牌没有问题，因为客户端ID和秘密是未知的。它还表明保持客户端ID和客户端机密是 重要 。 </DIV>

编辑
1#
回复此人
离线请留言 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 尽管上面有很多很好的答案，我作为一名安全硕士生和程序员，曾经在eBay工作过，当我看到买家保护和欺诈时，可以说分开访问令牌和刷新令牌有它的的 最佳平衡 </强> 骚扰用户之间的 频繁 </强> 用户名/密码输入并保持手中的权限以撤销对潜在的访问权限的 滥用 </强> 你的服务 想想这样的场景。您发出访问令牌为3600秒的用户，并将令牌更新为一天。 <OL> <LI> 用户是的 好 </强> 用户，他在家里，开着网站购物和搜索他的iPhone。他的IP地址不会改变，服务器负载也很低。像每分钟3-5页请求。当他在访问令牌上的3600秒结束时，他需要一个带有刷新令牌的新的令牌。我们在服务器端检查他的活动历史和IP地址，认为他是一个人，并且表现得很好。我们授予他一个新的访问令牌以继续使用我们的服务。用户不需要再次输入用户名/密码，直到他达到刷新令牌本身的一天为止。 </LI> <LI> 用户是的 粗心 </强> 用户。他生活在的 美国纽约 </强> 他的病毒程序被关闭，并被一名黑客入侵的 波兰 </强> 。当黑客获得访问令牌并刷新令牌时，他会尝试模拟用户并使用我们的服务。但是在短期访问令牌到期后，当黑客试图刷新访问令牌时，我们在服务器上发现了用户行为历史记录中的一个显着的IP更改（嘿，这个人在美国登录，现在刷新访问波兰仅仅3600s后???）。我们终止刷新过程，使刷新令牌本身无效并提示再次输入用户名/密码。 </LI> <LI> 用户是的 恶毒 </强> 用户。他打算通过使用机器人每分钟拨打1000次我们的API来滥用我们的服务。他可以这么做，直到3600秒后，当他试图刷新访问令牌时，我们注意到他的行为，并认为他可能不是一个人。我们拒绝并终止刷新过程并要求他再次输入用户名/密码。这可能会破坏机器人的自动流动。至少让他感到不舒服。 </LI> </醇> 当我们尝试平衡我们的工作，用户体验和被盗令牌的潜在风险时，您可以看到刷新令牌已经完美地发挥了作用。您在服务器端的看门狗可以检查超过IP更改，api调用的频率，以确定用户是否应该是一个好用户。 另一个词是你也可以尝试通过在每个api呼叫上实施基本的IP看门狗或任何其他措施来限制被盗令牌/滥用服务的损害控制。但这很昂贵，因为您必须读取和写入有关用户的记录，并会降低服务器响应速度。 </DIV>

编辑
2#
回复此人
⑩Ⅵ嵗Ｄ夨憶 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 客户可能在很多方面受到损害。例如，可以克隆手机。访问令牌过期意味着客户端被迫重新向授权服务器进行身份验证。在重新认证期间，授权服务器可以检查其他特征（IOW执行自适应访问管理）。 刷新令牌允许客户端仅重新进行身份验证，其中重新授权强制与用户进行对话，许多人已表示他们不愿意这样做。 刷新令牌基本上适合于普通网站可能选择在一小时左右（例如银行网站）后定期重新验证用户的相同位置。目前它没有被高度使用，因为大多数社交网站都没有重新验证网络用户，那么他们为什么要重新验证客户端呢？ </DIV>

编辑
3#
回复此人
v-star*위위 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> Catchdave提供的讨论链接还有另外一个 <a href="https://mailarchive.ietf.org/arch/browse/oauth/?gbt=1&index=WcWnHjObm6asw6x8acs4_8esGtM" rel="noreferrer"> 有效点 </A> <a href="http://www.ietf.org/mail-archive/web/oauth/current/msg07192.html" rel="noreferrer"> （原始，死链接） </A> 由Dick Hardt制作，除了上面所写的内容之外，我认为值得在这里提及： <BLOCKQUOTE> 我对刷新令牌的回忆是为了安全和撤销。＆LT; ...＆GT; 的 撤销： </强> 如果访问令牌是自包含的，则可以通过不发布新的访问令牌来撤销授权。资源不需要查询授权服务器以查看访问令牌是否有效。这简化了访问令牌验证，并使得更容易扩展和支持多个授权服务器。访问令牌有效时有一个时间窗口，但授权被撤销。 </BLOCKQUOTE> 实际上，在资源服务器和授权服务器是同一个实体的情况下，以及用户和它们中的任何一个之间的连接（通常）同样安全的情况下，将刷新令牌与访问令牌分开是没有多大意义的。 虽然，如引言中所述，刷新令牌的另一个作用是确保用户可以随时撤销访问令牌（例如，通过其配置文件中的Web界面），同时保持系统可扩展性同时。 通常，令牌可以是指向服务器数据库中特定记录的随机标识符，也可以包含所有信息（当然，这些信息必须签名， <a href="http://en.wikipedia.org/wiki/Message_authentication_code" rel="noreferrer"> 苹果电脑 </A> ，例如）。 的 具有长期访问令牌的系统应该如何工作 </强> 服务器允许客户端通过发出令牌来访问预定义范围集内的用户数据。由于我们希望保持令牌可撤销，我们必须在数据库中存储令牌以及设置或取消设置的标志“已撤销”（否则，如何使用自包含令牌执行此操作？）数据库可以包含尽可能多的内容 <code> len(users) x len(registered clients) x len(scopes combination) </code> 记录。然后，每个API请求都必须访问数据库。虽然对这样的数据库执行O（1）查询非常简单，但单点故障本身可能会对系统的可伸缩性和性能产生负面影响。 的 具有长期刷新令牌和短期访问令牌的系统应该如何工作 </强> 这里我们发出两个密钥：随机刷新令牌和数据库中的相应记录，以及签名的自包含访问令牌，其中包含到期时间戳字段。 由于访问令牌是自包含的，我们根本不需要访问数据库来检查其有效性。我们所要做的就是解码令牌并验证签名和时间戳。 尽管如此，我们仍然需要保留刷新令牌的数据库，但是对此数据库的请求数通常由访问令牌的生命周期定义（生命周期越长，访问率越低）。 为了撤销客户对特定用户的访问，我们应将相应的刷新令牌标记为“已撤销”（或完全删除）并停止发出新的访问令牌。很明显，虽然有一个窗口，在此窗口期间刷新令牌已被撤销，但其访问令牌可能仍然有效。 的 权衡 </强> 刷新令牌部分消除了访问令牌数据库的SPoF（单点故障），但它们有一些明显的缺点。 <OL> <LI> 窗户”。事件“用户撤销访问”和“访问保证被撤销”之间的时间范围。 </LI> <LI> 客户逻辑的复杂性。 的 无 </强> 刷新令牌 <UL> <LI> 使用访问令牌发送API请求 </LI> <LI> 如果访问令牌无效，则失败并要求用户重新进行身份验证 </LI> </UL> 的 同 </强> 刷新令牌 <UL> <LI> 使用访问令牌发送API请求 </LI> <LI>如果访问令牌无效，请尝试使用刷新令牌更新它 </LI> <LI> 如果刷新请求通过，则更新访问令牌并重新发送初始API请求 </LI> <LI> 如果刷新请求失败，请要求用户重新进行身份验证 </LI> </UL> </LI> </醇> 我希望这个答案确实有意义并帮助某人做出更周到的决定。我还要注意一些着名的OAuth2提供程序，包括github和foursquare，采用没有刷新令牌的协议，并且看起来很满意。 </DIV>

编辑
4#
回复此人
不见你 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 假设你使access_token持续很长时间，并且没有refresh_token，所以在一天内，黑客获得了这个access_token，他可以访问所有受保护的资源！ 但是如果你有refresh_token，那么access_token的实时时间很短，所以黑客很难破解你的access_token，因为它会在很短的时间后无效。 Access_token只能通过不仅使用refresh_token而且还可以通过client_id和client_secret（黑客没有）来检索。 </DIV>

编辑
5#
回复此人
一生浮华 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 这个答案来自Justin Richer通过OAuth 2标准正文电子邮件列表。这是在他的许可下发布的。 <HR /> 刷新令牌的生命周期取决于（AS）授权服务器，它们可以过期，被撤销等。刷新令牌和访问令牌之间的区别在于受众：刷新令牌仅返回授权服务器，访问令牌进入（RS）资源服务器。 此外，仅获取访问令牌并不意味着用户已登录。事实上，用户可能甚至不再在那里，这实际上是刷新令牌的预期用例。刷新访问令牌将允许您代表用户访问API，它不会告诉您用户是否在那里。 OpenID Connect不仅可以从访问令牌中为您提供用户信息，还可以为您提供ID令牌。这是一个单独的数据，它指向客户端本身，而不是AS或RS。在OIDC中，如果您可以获得新的ID令牌，您应该只考虑通过协议实际登录的人。刷新它可能不够。 欲了解更多信息，请阅读 <a href="http://oauth.net/articles/authentication/"> http://oauth.net/articles/authentication/ </A> </DIV>

编辑
6#
回复此人
NetworkAttachedStorage | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 让我们考虑一个系统，其中每个用户链接到一个或多个角色，每个角色都链接到一个或多个访问权限。可以缓存此信息以获得更好的API性能。但是，用户和角色配置可能会有变化（例如，可能会授予新访问权限或可能撤销当前访问权限），这些应该反映在缓存中。 我们可以为此目的使用访问和刷新令牌。使用访问令牌调用API时，资源服务器会检查缓存的访问权限。如果有任何新的访问授权，则不会立即反映。一旦访问令牌到期（例如在30分钟内）并且客户端使用刷新令牌生成新的访问令牌，就可以使用来自DB的更新的用户访问权限信息来更新缓存。 换句话说，我们可以使用访问令牌将昂贵的操作从每个API调用移动到使用刷新令牌生成访问令牌的事件。 </DIV>

编辑
7#
回复此人
蜡笔小辛 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <BLOCKQUOTE> 为什么不将access_token设置为与refresh_token一样长而没有refresh_token？ </BLOCKQUOTE> 除了其他人提供的很好的答案，还有另一个原因，为什么会使用刷新令牌和它与索赔。 每个令牌包含的声明可以包括来自用户名称，角色或创建声明的提供者的任何内容。随着令牌的刷新，这些声明会更新。 如果我们更频繁地刷新令牌，我们显然会对我们的身份服务施加更大的压力，但是我们正在获得更准确和最新的声明。 </DIV>

编辑
8#
回复此人
林老爷的日常 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 授权服务器保留刷新令牌。访问令牌是自包含的，因此资源服务器可以在不存储的情况下对其进行验证，从而节省了验证时的检索工作。讨论中缺少的另一点是来自rfc6749＃page-55 <BLOCKQUOTE> “例如，授权服务器可以使用刷新令牌每次访问都会发出新刷新令牌的轮换令牌刷新响应。之前的刷新令牌无效由授权服务器保留。如果是刷新令牌被攻击者和攻击者共同攻击并随后使用合法客户端，其中一个将呈现无效的刷新令牌，它将通知授权服务器违规。“ </BLOCKQUOTE> 我认为使用刷新令牌的重点是即使攻击者以某种方式设法获得刷新令牌，客户端ID和秘密组合。如果每次刷新请求都会产生新的访问令牌和刷新令牌，则可以跟踪从攻击者获取新访问令牌的后续调用。 </DIV>

编辑
9#
回复此人
布偶的表弟派大星丶 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <BLOCKQUOTE> 首先，客户端通过授权授权向授权服务器进行身份验证。 然后，客户端通过提供访问令牌向资源服务器请求受保护资源。 资源服务器验证访问令牌并提供受保护资源。 客户端通过授予访问令牌向资源服务器发出受保护资源请求，资源服务器在其中验证它并提供请求（如果有效）。此步骤将一直重复，直到访问令牌过期。 如果访问令牌过期，则客户端通过授权服务器进行身份验证，并通过提供刷新令牌来请求新的访问令牌。如果访问令牌无效，资源服务器会将无效令牌错误响应发送回客户端。 客户端通过授予刷新令牌来向授权服务器进行身份验证。 然后，授权服务器通过验证客户端验证刷新令牌，并发出新的访问令牌（如果有效）。 </BLOCKQUOTE> </DIV>

编辑

登录后才能参与评论