OAuth 2.0中的授权请求和授权授权

Question

我不理解OAuth过程中第一步的概念:授权请求和授权授权。据我所知：

1. 用户希望通过授权Service访问客户端
2. 用户单击例如“使用Github登录”，然后重定向到Service的网站
3. 用户通过单击例如“授权客户端”来授权客户端
4. 服务API向客户发送授权授予的批准。
5. 客户端使用授权授予请求令牌。
6. 服务API返回访问令牌。
7. 客户端使用访问令牌请求受保护的资源。
8. 服务API发回资源
9. 客户端向用户显示资源。

这个流程正确吗？我对用户在请求/授予授权方面的作用感到特别困惑。

Answer 1

OAuth2 RFC非常广泛，涵盖了许多用例。由于您的问题是针对最常见的用例，即“登录与”按钮，我们将只讨论这一点。

让我们先把角色调好：

User:资源的所有者。例如，用户拥有一个电子邮件amey@example.com。

Client:请求用户拥有的信息的应用程序。这是托管按钮'Sign‘的应用程序。

资源:客户端请求的信息。客户可能需要访问您的电子邮件，您的出生日期和您的个人资料图片。

授权服务器:负责授权客户端请求访问用户资源的服务器。

资源服务器( Resource )：一种服务器，它保存用户的资源，并在显示有效的凭据时将其传输给用户。

OAuth2设置:希望访问资源服务器上承载的用户信息或资源的应用程序应首先向资源的授权服务注册。这一步骤所需的信息如下：

1. 客户端FQDN
2. 客户端的回调或重定向URL

在成功地向授权服务注册时，客户端将收到一个clientId，它将在身份验证过程中发送到授权服务器。

身份验证过程：

假设用户想要向客户端(例如，client.com)证明他们是电子邮件amey@example.com的合法所有者。

步骤1:用户点击客户端网站上的“example.com登录”。我们叫它client.com吧。

步骤2:这会产生OAuth2身份验证流。将使用以下参数调用资源服务器的OAuth2 URL：

1. clientID
2. 重定向URL
3. 状态(随机生成的当前状态，不是每个OAuth2所必需的，而是通常使用的)
4. 类型(代码是最常用的，这是您开始时最不需要知道的。(下文将对此作更多介绍。)
5. 作用域

URL将如下所示：https://example.com/oauth2?state=018aed36-8f70-4fcb-a49f-0eba5cee22ff&redirectURL=https://client.com/oauth2/callback&scope=email+profile.info&type=code

步骤3:授权服务器在向用户显示身份验证对话框之前对请求执行以下检查：

1. 请求中的引用头与客户端在安装过程中注册的clientID正确地对应。
2. 重定向URL与注册的clientID正确对应。
3. 请求的信息范围对于授权服务器来说是可以接受的。这可能是基于在登记期间提供的信息或其他一些因素。

步骤4:授权服务器向用户提供一个身份验证对话框。在成功的身份验证中，授权服务器生成随机代码。还记得上面第二步的类型参数吗？type=code参数告诉授权服务器，客户端需要当前OAuth2身份验证请求的一次性授权代码。这不是最终的授权令牌。授权代码是短暂的，它们提供了一层额外的安全性，以保护资源服务器将授予的授权令牌。代码本身对对手没有任何用处。

步骤5:授权服务器将用户浏览器重定向到client.com的重定向URL，该重定向URL包含在上述步骤2的第一个OAuth2调用中，并将代码参数与状态参数一起附加到请求中(通常在OAuth2查询中)

重定向URL如下所示：https://client.com/oauth2/callback?state=018aed36-8f70-4fcb-a49f-0eba5cee22ff&code=3b9d8826-55b5-4e0a-b441-3137c2e9f864

步骤6:当client.com服务器接收到此请求时，它将调用授权服务器并发送从用户浏览器接收的授权代码。授权服务器使用授权令牌响应此请求，该令牌可用于根据约定的范围为用户请求信息。

步骤7: client.com的服务器调用将授权令牌附加到Resource，以获取用户的电子邮件地址。资源服务器再次向授权服务器发送请求，以验证令牌是否正确，所请求的资源是否在授权范围内。一旦获得授权服务器的授权，资源服务器就会将请求的资源发送给client.com的服务器，在本例中，用户的电子邮件地址(amey@example.com)。一旦client.com服务器从资源服务器接收到此信息，它就可以愉快地得出用户是该电子邮件地址的合法所有者的结论。服务器发送用于维护客户端会话的cookie或任何其他令牌，并允许用户使用client.com的应用程序。

步骤6和步骤7对用户隐藏。通信直接发生在客户端服务器和资源服务器之间。因此，当您等待客户端的响应时，一开始想象后端发生了什么可能会让人感到困惑。

您可以查看下面的图像，以获得流程的描述性流程：

图像属性：https://medium.com/@darutk/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85

也将有助于阅读这篇博文，使之更清晰。