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。
- OAuth是授权规范。 它通常与身份验证规范一起使用,例如Open Connect,但这实际上是一个单独的规范。
翻译自: https://www.javacodegeeks.com/2018/08/oauth-authorisation-code-grant.html