在较高的层面上，OAuth 2如何运作？

作者: 不见你
发布时间: 2024-12-15 12:19:57 (2月前)
转自：

8 条回复

0#
回复此人
我头上有犄角 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 图1，解除了 <a href="https://tools.ietf.org/html/rfc6750"> RFC6750 </A> ： <pre> <code> +--------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+ </code> </pre> </DIV>

编辑
1#
回复此人
筱梨 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 这是一个宝石： <a href="https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2" rel="noreferrer"> https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2 </A> 的 非常简短的总结： </强> OAuth定义了四个角色： <OL> <LI> 资源所有者 </LI> <LI> 客户 </LI> <LI> 资源服务器 </LI> <LI> 授权服务器 </LI> </醇> 你（资源所有者）有一部手机。您有几个不同的电子邮件帐户，但您希望在一个应用程序中使用所有电子邮件帐户，因此您无需继续切换。因此，您的GMail（客户端）要求（通过Yahoo的授权服务器）访问您的Yahoo电子邮件（资源服务器），以便您可以在GMail应用程序上阅读这两封电子邮件。 OAuth存在的原因是因为GMail存储您的Yahoo用户名和密码是不安全的。 <a href="https://i.stack.imgur.com/6CMie.png" rel="noreferrer"> <img src =“https://i.stack.imgur.com/6CMie.png”alt =“在此输入图片说明”/> </A> </DIV>

编辑
2#
回复此人
听风～ | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 这可能是OAuth2如何适用于所有4种授权类型的最简单的解释，即应用程序可以获取访问令牌的4种不同流程。 的 相似 </强> 所有授权类型流程都有两部分： <UL> <LI> 获取访问令牌 </LI> <LI> 使用访问令牌 </LI> </UL> 第二部分 '使用访问令牌' 对于所有流程都是一样的 的 区别 </强> 流程的第一部分 '获取访问令牌' 每种拨款类型各不相同。 但是，一般而言 '获取访问令牌' 部分可归纳为包含5个步骤： <OL> <LI> 使用OAuth提供商（例如Twitter等）预先注册您的应用（客户端）以获取客户端ID /机密 </LI> <LI> 创建一个客户端ID为＆amp;的社交登录按钮。页面上所需的范围/权限，因此当点击的用户被重定向到OAuth提供程序以进行身份验证时 </LI> <LI> OAuth提供商请求用户授予您的应用（客户端）权限 </LI> <LI> OAuth提供商发布代码 </LI> <LI> App（客户端）获取访问令牌 </LI> </醇> 下面是一个并排的图表，根据5个步骤比较每个授权类型流程的不同之处。 该图来自 <a href="https://blog.oauth.io/introduction-oauth2-flow-diagrams/" rel="nofollow noreferrer"> https://blog.oauth.io/introduction-oauth2-flow-diagrams/ </A> <a href="https://i.stack.imgur.com/kC8bX.png" rel="nofollow noreferrer"> <img src =“https://i.stack.imgur.com/kC8bX.png”alt =“在此处输入图片说明”/> </A> 每个都有不同级别的实现难度，安全性和用例。根据您的需要和情况，您将不得不使用其中一个。哪个用？ 的 客户凭据 </强> ：如果您的应用仅为单个用户提供服务 的 资源所有者密码Crendential </强> ：这应该仅作为最后的手段使用，因为用户必须将他的凭据移交给应用程序，这意味着应用程序可以执行用户可以执行的所有操作 的 授权码 </强> ：获得用户授权的最佳方式 的 含蓄 </强> ：如果您的应用是移动应用或单页应用 这里有更多的选择解释： <a href="https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/" rel="nofollow noreferrer"> https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/ </A> </DIV>

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

<div class =“post-text”itemprop =“text”> 另一个答案非常详细，解决了OP提出的大部分问题。 为了详细阐述，特别是解决OP的问题“OAuth 2如何使用安全令牌防止重放攻击？”，官方建议中还有两个额外的保护措施。 实施 OAuth 2： 1）代币通常有一个短的有效期（ <a href="http://tools.ietf.org/html/rfc6819#section-5.1.5.3"> http://tools.ietf.org/html/rfc6819#section-5.1.5.3 </A> ）： <BLOCKQUOTE> 令牌的短暂到期时间是一种防范手段以下威胁： <UL> <LI> 重播... </LI> </UL> </BLOCKQUOTE> 2）当站点A使用令牌时，建议不会将其显示为URL参数，而是显示在授权请求头字段中（ <a href="http://tools.ietf.org/html/rfc6750"> http://tools.ietf.org/html/rfc6750 </A> ）： <BLOCKQUOTE> 客户端应该使用承载令牌进行经过身份验证的请求具有“承载”HTTP的“授权”请求头字段授权方案。 ... 不应该使用“application / x-www-form-urlencoded”方法除了在参与浏览器没有的应用程序上下文中可以访问“授权”请求标头字段。 ... 包含URI查询参数...以记录当前使用情况;它的用途不是建议，由于其安全性不足 </BLOCKQUOTE> </DIV>

编辑
4#
回复此人
敢嫁就敢娶 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 基于我所读到的，这就是它的工作原理： 问题中概述的一般流程是正确的。在步骤2中，用户X经过身份验证，并且还授权站点A访问站点B上的用户X的信息。在步骤4中，站点将其秘密传递回站点B，验证自身以及授权码，指示什么它要求（用户X的访问令牌）。 总的来说，OAuth 2实际上是一个非常简单的安全模型，加密永远不会直接发挥作用。相反，Secret和Security Token本质上都是密码，整个事情只能通过https连接的安全性来保护。 OAuth 2无法防御安全令牌或机密的重放攻击。相反，它完全依赖于站点B对这些项目负责而不让他们离开，并且在传输过程中通过https发送它们（https将保护URL参数）。 授权代码步骤的目的仅仅是方便，授权代码本身并不特别敏感。当向站点B询问用户X的访问令牌时，它为站点A的用户X访问令牌提供公共标识符。只是用户X在站点B上的用户ID不起作用，因为可能有许多未完成的访问令牌等待同时发送到不同的站点。 </DIV>

编辑
5#
回复此人
無口君 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> OAuth是一种协议，三方应用可以使用该协议访问存储在另一个网站中的数据而无需您的帐户和密码。有关更官方的定义，请参阅Wiki或规范。 这是一个用例演示： <OL> <LI> 我登录LinkedIn并想要连接我的Gmail联系人中的一些朋友。 LinkedIn支持这一点。它将从gmail请求安全资源（我的gmail联系人列表）。所以我点击这个按钮： <img src =“https://i.stack.imgur.com/hSmux.png”alt =“添加连接”/> </LI> <LI> 当我输入我的帐户和密码时，会弹出一个网页，并显示Gmail登录页面： <img src =“https://i.stack.imgur.com/3QvQo.png”alt =“添加连接”/> </LI> <LI> 然后Gmail会显示一个同意页面，点击“接受”： <img src =“https://i.stack.imgur.com/lQjip.png”alt =“添加连接”/> </LI> <LI> 现在LinkedIn可以访问Gmail中的联系人： <img src =“https://i.stack.imgur.com/ymoap.png”alt =“添加连接”/> </LI> </醇> 以下是上述示例的流程图： <img src =“https://i.stack.imgur.com/bt7k0.png”alt =“添加连接”/> 第1步：LinkedIn从Gmail的授权服务器请求令牌。 第2步：Gmail授权服务器对资源所有者进行身份验证，并向用户显示同意页面。（如果用户尚未登录，则需要登录Gmail） 第3步：用户授予LinkedIn访问Gmail数据的请求。 第4步：Gmail授权服务器使用访问令牌回复。 第5步：LinkedIn使用此访问令牌调用Gmail API。 第6步：如果访问令牌有效，Gmail资源服务器会返回您的联系人。（该令牌将由Gmail资源服务器验证） 您可以从OAuth的详细信息中获得更多信息 <a href="http://helloowen.com/blog/Tech-What-is-OAuth.html" rel="noreferrer"> 这里 </A> 。 </DIV>

编辑
6#
回复此人
机器设备维修 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 这就是Oauth 2.0的工作方式，并在其中得到了很好的解释 <a href="https://dzone.com/articles/oauth-20-beginners-guide" rel="noreferrer"> 本文 </A> <a href="https://i.stack.imgur.com/Mo2wi.jpg" rel="noreferrer"> <img src =“https://i.stack.imgur.com/Mo2wi.jpg”alt =“在此处输入图片说明”/> </A> </DIV>

编辑

登录后才能参与评论