OAUTH 2.0授权码授予

OAuth 2.0提供了许多安全性流程（或授权类型），以允许一个应用程序访问另一个应用程序中的用户数据。

在此博客中，我们将介绍OAuth 2.0授权：授权代码授权。

首先，有许多定义：

客户端 ：用户当前正在与之交互的应用程序。例如，我们假设一个虚构的时髦博客网站：www.myfunkyblog.com。客户端希望与另一个应用程序通信并从那里检索有关用户的信息。例如，他们最喜欢的照片！让我们假设虚拟的megaphotosharing.com作为服务客户希望访问。
客户ID ：这是标识客户的ID。可以在Web URL等中公开传递
客户机密ID ：只有客户知道的机密ID。这保留在服务器端，将用于对要访问的应用程序的请求中。它不能在Web URL中传递。
资源拥有者 ：这通常是人，谁在使用客户端应用程序。资源所有者在客户端（ myfunkyblog.com ）希望访问的另一个应用程序（例如megaphotosharing.com）中具有数据。目的是在无需资源所有者（也就是人类）将其megaphotosharing.com密码传递到myfunkyblog.com的情况下，促进共享。注意：资源所有者不必是人类，但根据OAuth规范，有趣的是，资源所有者是人类时，也可以称为最终用户。
资源服务器 ：托管客户端感兴趣的资源所有者的受保护资源。因此，这是megaphotosharing.com服务器，其中具有myfunkyblog.com感兴趣的资源所有者的照片。
授权服务器 ：在资源所有者成功通过身份验证并允许myfunkyblog.com获得其megaphotosharing.com的 一部分之后，向myfunkyblog.com发行令牌的服务器。有时，授权服务器和资源服务器实际上是相同的，但不必相同。
访问令牌 ： myfunkyblog.com授权服务器提供的一种特殊类型的令牌，使megaphotosharing.com可以访问受保护的资源。它将包含范围，生存期和其他访问属性。

用例

因此，用例是客户端（ myfunkyblog.com ）希望从另一个应用程序megaphotosharing.com访问有关资源所有者（人）的信息。

客户注册

客户首先要做的是向服务（ megaphotosharing.com ）注册，并提供其名称，网站等。该服务将返回一个秘密的客户代码。

客户将其保密，并负责确保只有其知道。通常，它将加密并将其持久化在后端的客户端中。该服务还将收到一个客户端ID。与客户机密不同，这是公开的，可以在URL等中传递。

流

好吧，现在是实际流量。

用户正在myfunkyblog.com上浏览，并访问myfunkyblog.com想要了解最终用户最喜欢的照片的网站的一部分。

最终用户将看到一个弹出屏幕。

该网址：

https://megaphotosharing.com/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL≻ope=read

该网址的关键部分：

megaphotosharing.com：这是授权服务器的域
response_type = code：启用客户端所需的参数将通知授权服务器所需的授予类型。一个替代值是“令牌”，用于隐式流。 “代码”表示客户端需要授权码 ，该授权码将在资源所有者登录后返回。该授权码将在客户端的后续请求中使用。
client_id：必需参数，用于标识客户端。请记住，这是公开的
可以在Web浏览器之间传递。
redirect_uri：这是一个可选参数。它使客户端可以动态指定身份验证服务器应重定向到的URL。 在某些流程中，这是不需要的，因为只有一个重定向URI，并且它在客户端注册期间由客户端向服务注册。
作用域：这是一个可选参数。它指定应用程序正在请求的访问级别。在这种情况下，这只是读取。身份验证服务器使用它来通知用户/资源所有者客户端正在尝试执行的操作。

然后，用户登录megaphotosharing.com，告诉用户客户端要做什么。如果用户选择“确定”，则megaphotosharing.com将重定向到传递的重定向URI。

https://myfunkyblog.com/callback?code=212132kjhkhj

注意客户端ID是如何通过URL 在Web上传递的并将授权代码通过网络传回。

然后，客户端使用返回的授权代码，其客户端ID，客户端密码和授予类型来向服务器发送POST请求，以获取访问令牌。这一切都发生在后端。

https://megaphotosharing.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code= 212132kjhkhj&redirect_uri=CALLBACK_URL

笔记：

客户ID和客户机密标识客户。这是一个后端请求，因此可以传递client_secret（显然不会传递给浏览器或从浏览器传递）。
grant_type：必须将其设置为authorisation_code。因为它表示授权码授予。请记住，授予用于指示客户端正在使用的流（服务器也可以使用哪些类型的可用流）。 如果客户端正在使用“客户端证书授予”，则该值为：“ client_credentials”。 如果客户端使用“资源所有者密码凭据授予”，则该值为“密码”。
代码： 212132kjhkhj –实际授权码，是从授权服务器发出的初始授权请求中返回的内容。这是必需的。
redirect_uri：如果redirect_uri包含在授权请求中，则该值必须与该请求中使用的值相同。

客户端然后接收回访问令牌。像这样：

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":1001013121222}

现在它将使用它来访问某些资源所有者的资源数据。

那有什么大不了的？

对于用户不必告诉一个网站另一个网站的密码来说，显然有很大的优势。
减少用户需要记住的密码数量
通过允许不同的应用程序相互通信，可以提供更丰富的网站。

人们为什么会感到困惑？

人们发现OAuth 2.0令人困惑的原因有很多。

有一些不同的流程或赠款。 授权码授予只是其中之一。有时，当您在Google上搜索OAuth 2.0的说明时，会得到针对不同补助金的说明，而没有弄清楚到底是什么还是没有解释。因此，为什么要在标题中添加授权码授予。
术语。我只为自己说话。但是，如果我快速阅读，我可能会：
- 将“客户”与最终用户混淆

一致。许多地方都实现了OAuth 2.0或与OAuth非常相似的东西，但是在此过程中它们的引用方式有所不同。例如，转到quora.com，然后尝试登录google。您将被带到：

https://accounts.google.com/signin/oauth/oauthchooseaccount?client_id=917071888555.apps.googleusercontent.com&as=rdWeinbqWJbt6ChoW2f3Fg&destination=https%3A%2F%2Fwww.quora.com≈proval_state=!ChRyQlhnbEYzai1xQTliNlNmTEVmNRIfZ3doM2hlRVIycGdiMEVBN1JaNXdOM085MERXLVVCWQ%E2%88%99ANKMe1QAAAAAW2i2to0SOyO2_w3k3O4gjwUKQLGNmZ2h&oauthgdpr=1&xsrfsig=AHgIfE8EzSxvWfzyxou0dwLDxv4GhD6e5g&flowName=GeneralOAuthFlow

该URL中没有response_type。