澄清 OAUTH 2 授予类型 [英] Clarification of OAUTH 2 Grant Types

查看:51
本文介绍了澄清 OAUTH 2 授予类型的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

一直在阅读有关 OAUTH2 的内容.

Been doing some reading regarding OAUTH2.

所以...

  • 授权码授予:适用于希望通过第三方应用程序访问我的应用程序/API 的用户.示例:用户通过 Flicker 想要访问我的照片打印 API.在这种情况下,Flicker 将使用 MY 服务器进行所有重定向和 OAUTH2 流.提供访问令牌,第 3 方应用程序可以根据需要使用 MY API.应用程序开发人员需要注册才能获取客户端 ID 和客户端密码.

  • Authorisation Code Grant: Is for users who want to access MY application/API through a third party application. Example: A user through Flicker wants to access MY photo printing API. In this case Flicker will do all the redirection and the OAUTH2 flow with MY servers. Access token is provided and 3rd party application can use MY API as needed. The application developer will need to register to get the client id and client secret.

隐式: 与上述相同,但移动/应用程序没有后端服务器来保护客户端机密.移动应用程序将处理重定向和 OAUTH2 流.提供访问令牌,第 3 方应用程序可以根据需要使用 MY API.不支持刷新令牌.应用程序开发人员需要注册才能获取客户端 ID.

Implicit: Same as above except the mobile/app doesn't have a back end server to safekeep the client secret. The mobile app will handle redirect and OAUTH2 flow. Access token is provided and 3rd party application can use MY API as needed. Refresh token not supported. The application developer will need to register to get the client id.

资源所有者密码凭据授予:在这种情况下,这是我通过典型的 iTunes/Play 商店分发给我的用户的移动/网络应用程序.用户严格使用我的应用程序来做他们的日常工作.我的移动/网络应用程序将要求用户提供用户名/密码,并将它们发布到我的后端进行身份验证,然后返回访问令牌.

Resource Owner Password Credentials Grant: In this case, this is MY mobile/web app that I distribute to my users through the typical iTunes/Play stores. The users strictly use MY app to do their day to day stuff. MY mobile/web app will ask the user for Username/Password and post them to MY back end where it will authenticate and then provide back the access token.

客户端凭据授予:此案例用于应用程序执行内部机器对机器的操作.即:我的 App1 在后端某处访问了我的 App2.

Client credentials grant: This case is used for application to do internal machine to machine stuff. I.e: MY App1 accessed MY App2, in the back end somewhere.

目前我预计不会与第 3 方共享我的 API,我的用户将通过 iTunes/google play 安装我的应用程序.我想密码凭证现在对我很有用.最终,如果我想向世界其他地方开放我的 API,我将不得不实施授权代码授予

For now I do not foresee sharing my API with 3rd parties and my users will install MY app through iTunes/google play. I suppose that Password Credentials is good for me right now. Eventually if I want to open up my API to the rest of the world I will have to implement Authorisation Code Grant

当我四处寻找这个主题时,我发现了这个链接:https://alexbilbie.com/guide-to-oauth-2-grants/ 有一个很好的决策流程.

As I searched around for this subject, I came across this link: https://alexbilbie.com/guide-to-oauth-2-grants/ which has a nice decision flow.

推荐答案

OAuth2 用于将您的资源的访问权限授权/委托给客户端(第三方应用程序).

OAuth2 is used when you want to authorize/delegate access on your resources to a client (third party application).

至少有 4 个演员:

  • 授权服务器
  • 客户
  • 资源所有者
  • 资源服务器

应用程序/API 是资源服务器.它存储和管理资源所有者的所有资源.

The application/API is the resource server. It stores and manages all resources of the resource owner.

客户端是想要访问这些资源的一方.授权服务器是通过颁发访问令牌来授权客户端访问资源的服务器.

The client is the party who want to access on those resources. The authorization server is the server who authorize client to access on resources by issuing an access token.

  • 授权码授予专为机密客户设计(能够保护其凭据的安全).
  • Implicit Grant 是为公共客户端(而非机密客户端)设计的,尤其是为脚本语言应用程序 (JS...) 设计
  • Resource Owner Password Credentials Grant 适用于任何类型的客户端,但假设客户端知道资源的密码凭据.通常,此授权类型仅适用于受信任的客户.
  • Client Credentials Grant 允许客户端访问自己的资源(在这种情况下,资源所有者是客户端).

应避免使用资源所有者密码凭据授予,但它仍然是遗留应用程序的一个很好的解决方案,并且如果客户端之间存在信任关系,授权服务器资源服务器.

The use of the Resource Owner Password Credentials Grant should be avoided, however it remains a good solution for legacy applications and if there is a trusted relationship between the client, the authorization server and the resource server.

这篇关于澄清 OAUTH 2 授予类型的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆