东莞做网站首选,网站建设报价单表格模板,wordpress搭建影视站,苏州马可波罗网站建设oauth2.0授权码OAuth 2.0提供了许多安全流程#xff08;或授权类型#xff09;#xff0c;以允许一个应用程序访问另一个应用程序中的用户数据。 在此博客中#xff0c;我们将介绍OAuth 2.0授权#xff1a;授权代码授权。 首先#xff0c;有许多定义#xff1a; 客户… oauth2.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后的资源拥有者成功验证并允许myfunkyblog.com获得一些megaphotosharing.com的服务器。 有时授权服务器和资源服务器实际上是相同的但不必相同。 访问令牌 myfunkyblog.com授权服务器提供的一种特殊类型的令牌使megaphotosharing.com可以访问受保护的资源。 它将包含范围生存期和其他访问属性。 用例 因此用例是客户端 myfunkyblog.com 希望从另一个应用程序megaphotosharing.com访问有关资源所有者人的信息。 客户注册 客户首先要做的是向服务 megaphotosharing.com 注册并提供其名称网站等。该服务将返回一个秘密的客户代码。 客户将其保密并负责确保只有其知道。 通常它将加密并将其持久化在后端的客户端中。 该服务还将收到一个客户端ID。 与客户机密不同这是公开的可以在URL等中传递。 流 好吧现在是实际流量。 用户正在myfunkyblog.com上浏览并访问myfunkyblog.com想要了解最终用户最喜欢的照片的网站的一部分。 最终用户将看到一个弹出屏幕。 该网址 https://megaphotosharing.com/oauth/authorize?response_typecodeclient_idCLIENT_IDredirect_uriCALLBACK_URL≻operead 该网址的关键部分 megaphotosharing.com这是授权服务器的域 response_type code启用客户端所需的参数通知授权服务器所需的授予类型。 一个替代值是“令牌”用于隐式流。 “代码”表示客户端需要授权码 该授权码将在资源所有者登录后返回。该授权码将在客户端的后续请求中使用。 client_id必需参数用于标识客户端。 请记住这是公开的 可以在Web浏览器之间传递。 redirect_uri这是一个可选参数。 它使客户端可以动态指定身份验证服务器应重定向到的URL。 在某些流程中这是不需要的因为只有一个重定向URI并且在客户端注册过程中由客户端使用服务进行了注册。 作用域这是一个可选参数。 它指定应用程序正在请求的访问级别。 在这种情况下这只是读取。 身份验证服务器使用它来通知用户/资源所有者客户端正在尝试执行的操作。 然后用户登录megaphotosharing.com告诉用户客户端要做什么。 如果用户选择“确定”则megaphotosharing.com将重定向到传递的重定向URI。 https://myfunkyblog.com/callback?code212132kjhkhj 注意客户端ID如何通过URL 在Web上传递 并将授权代码通过网络传回。 然后客户端使用返回的授权码客户端ID客户端密码和授予类型来向服务器发送POST请求以获取访问令牌。 这一切都发生在后端。 https://megaphotosharing.com/v1/oauth/token?client_idCLIENT_IDclient_secretCLIENT_SECRETgrant_typeauthorization_codecode 212132kjhkhjredirect_uriCALLBACK_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_id917071888555.apps.googleusercontent.comasrdWeinbqWJbt6ChoW2f3Fgdestinationhttps%3A%2F%2Fwww.quora.com≈proval_state!ChRyQlhnbEYzai1xQTliNlNmTEVmNRIfZ3doM2hlRVIycGdiMEVBN1JaNXdOM085MERXLVVCWQ%E2%88%99ANKMe1QAAAAAW2i2to0SOyO2_w3k3O4gjwUKQLGNmZ2hoauthgdpr1xsrfsigAHgIfE8EzSxvWfzyxou0dwLDxv4GhD6e5gflowNameGeneralOAuthFlow 该URL中没有response_type。 OAuth是一种授权规范。 它通常与身份验证规范一起使用例如Open Connect但这实际上是一个单独的规范。 翻译自: https://www.javacodegeeks.com/2018/08/oauth-authorisation-code-grant.htmloauth2.0授权码
