介绍
OAuth 2是一种授权框架，使应用程序能够获得对HTTP服务（如Facebook，GitHub和DigitalOcean）上的用户帐户的有限访问权限。 它通过将用户身份验证委托给托管用户帐户的服务，并授权第三方应用程序访问用户帐户。 OAuth 2为Web和桌面应用程序以及移动设备提供授权流程。
本信息指南面向应用程序开发人员，并提供OAuth 2角色，授权许可类型，用例和流的概述。
让我们开始使用OAuth角色！
OAuth角色
OAuth定义了四个角色：
- 资源所有者
- 客户
- 资源服务器
- 授权服务器
我们将在以下各小节中详细介绍每个角色。
资源所有者： 用户
资源所有者是谁授权的应用程序来访问他们的帐户的用户 。 应用程序对用户帐户的访问权限仅限于授予的授权（例如读取或写入访问权限）的“范围”。
资源/授权服务器：API
资源服务器承载保护的用户帐户和授权服务器验证用户的身份，然后发出访问令牌给应用程序 。
但从应用程序开发者的角度来看，一个服务的API，同时满足资源和授权服务器角色。 我们将把这两个角色结合起来，作为服务或API的作用。
客户： 应用程序
客户端想要访问用户的帐户中的应用 。 在它可以这样做之前，它必须由用户授权，并且授权必须由API验证。
抽象协议流
现在，您已经了解OAuth角色的作用，让我们看一下它们通常如何互动的图表：
下面是图中步骤的更详细说明：
- 该应用程序请求授权从用户访问服务资源
- 如果用户授权请求时， 应用程序接收到授权许可
- 该应用程序请求从授权服务器 （API）通过提供自己的身份验证访问令牌，并授权拨款
- 如果应用程序的身份被认证和授权许可是有效的，所述授权服务器 （API），发出一个访问令牌给应用程序。 授权完成。
- 该应用程序从资源服务器 （API）请求的资源，并提出了验证访问令牌
- 如果该访问令牌是有效的， 资源服务器 （API），用于该资源的应用程序
此过程的实际流程将根据使用的授权许可类型而有所不同，但这是一般的想法。 我们将在后面的章节中探讨不同的授权类型。
申请注册
在对您的应用程序使用OAuth之前，您必须使用该服务注册您的应用程序。 通过服务网站的“开发人员”或“API”部分中的注册表单，您将提供以下信息（以及可能有关您的申请的详细信息）：
- 应用名称
- 应用网站
- 重定向URI或回调URL
重定向URI是服务在用户授权（或拒绝）您的应用程序之后重定向用户的位置，因此您的应用程序将处理授权码或访问令牌的部分。
客户端ID和客户端密钥
一旦您的申请注册，该服务将在客户端标识和客户端密钥的形式颁发的“客户端凭据”。 客户端ID是公开显示的字符串，由服务API用于标识应用程序，也用于构建向用户显示的授权URL。 当应用请求访问用户的帐户时，客户端秘密用于对服务API的应用的身份进行认证，并且必须在应用和API之间保持私有。
授权授权
在抽象协议流之上，前四个步骤包含获得授权赠款和访问令牌。 授权授权类型取决于应用程序请求授权所使用的方法以及API支持的授权类型。 OAuth 2定义了四种授权类型，每种授权类型在不同情况下都很有用：
- 验证码 ：与服务器端应用程序使用
- 隐式 ：使用移动应用或Web应用程序使用（即在用户的设备上运行的应用程序）
- 资源所有者密码凭据 ：与可信赖的应用，如那些由服务本身拥有的使用
- 客户端凭证 ：与应用程序的API访问使用
现在我们将在以下部分更详细地描述授权类型，它们的用例和流程。
授权类型：授权代码
授权代码授予类型是最常用的，因为它是服务器端应用中 ，源代码没有公开暴露出来，和客户端秘密的保密优化得以维持。 这是一种基于重定向流的，这意味着应用程序必须能与用户代理 （即在用户的网络浏览器）进行交互和接收通过用户代理路由的API的授权代码。
现在我们将描述授权码流程：
第1步：授权码链接
首先，给用户一个授权码链接，如下所示：
https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read
这里是链接组件的解释：
- https://cloud.digitalocean.com/v1/oauth/authorize ：该API授权端点
- CLIENT_ID = CLIENT_ID：应用程序的客户端ID（该API如何识别应用）
- REDIRECT_URI = CALLBACK_URL：其中一个授权码，被授予后，该服务将用户重定向代理
- RESPONSE_TYPE = 代码 ：指定应用程序请求授权代码授权
- 范围= 读 ：指定的访问级别应用程序请求
第2步：用户授权应用程序
当用户单击链接时，他们必须首先登录到服务，以验证其身份（除非他们已经登录）。 然后，他们将通过服务提示授权或拒绝其帐户应用程序访问。 这里是一个示例authorize应用程序提示：
这种特殊的截图是DigitalOcean授权屏幕，我们可以看到，“Thedropletbook应用程序”请求为“读”访问帐户的“授权manicas@digitalocean.com ”。
第3步：应用程序接收授权代码
如果用户点击“授权应用程序”，该服务将用户重定向代理应用程序重定向URI，这是客户注册时指定， 授权代码 。 重定向看起来像这样（假设应用程序是“dropletbook.com”）：
https://dropletbook.com/callback?code=AUTHORIZATION_CODE
第4步：应用程序请求访问令牌
该应用程序请求访问令牌从API，通过将授权码与认证细节一起，包括客户端秘密 ，到API令牌端点。 这里是一个示例POST请求到DigitalOcean的令牌端点：
https://cloud.digitalocean.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL
第5步：应用程序接收访问令牌
如果授权有效，API将向应用程序发送包含访问令牌（以及可选的刷新令牌）的响应。 整个响应看起来像这样：
{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"mark@thefunkybunch.com"}}
现在应用程序已授权！ 它可以使用令牌通过服务API访问用户的帐户，限于访问的范围，直到令牌过期或被撤销。 如果发出了刷新令牌，则如果原始令牌已过期，则可以使用刷新令牌来请求新的访问令牌。
授予类型：隐式
隐含补助类型用于移动应用程序和Web应用程序（即在网页浏览器中运行的应用程序，即），其中客户端秘密保密性无法得到保证。 隐式授权类型也是基于重定向的流，但是接入令牌被给予用户代理以转发到应用，因此它可以暴露给用户和用户设备上的其他应用。 此外，此流不认证应用程序的身份，并且依赖重定向URI（已向服务注册）来实现此目的。
隐式授权类型不支持刷新令牌。
隐式授权流程基本上如下工作：要求用户授权应用程序，然后授权服务器将访问令牌传递回用户代理，并将其传递给应用程序。 如果你对细节好奇，请继续阅读。
第1步：隐式授权链接
使用隐式授权类型，向用户呈现授权链接，该请求从API请求令牌。 这个链接看起来就像授权码链接，除了它是请求令牌 ，而不是代码（注意响应类型 “令牌”）：
https://cloud.digitalocean.com/v1/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read
第2步：用户授权应用程序
当用户单击链接时，他们必须首先登录到服务，以验证其身份（除非他们已经登录）。 然后，他们将通过服务提示授权或拒绝其帐户应用程序访问。 这里是一个示例authorize应用程序提示：
我们可以看到，“Thedropletbook应用程序”请求授权“读”访问帐户的“ manicas@digitalocean.com ”。
第3步：用户代理接收带有重定向URI的访问令牌
如果用户单击“授权应用程序”，则服务将用户代理重定向到应用程序重定向URI，并包括包含访问令牌的URI片段。 它看起来像这样：
https://dropletbook.com/callback#token=ACCESS_TOKEN
第4步：用户代理遵循重定向URI
user-agent跟随重定向URI，但保留访问令牌。
第5步：应用程序发送访问令牌提取脚本
应用程序返回包含脚本的网页，该脚本可以从用户代理保留的完全重定向URI中提取访问令牌。
第6步：访问令牌传递到应用程序
用户代理执行所提供的脚本，并将提取的访问令牌传递给应用程序。
现在应用程序已授权！ 它可以使用令牌通过服务API访问用户的帐户，限于访问的范围，直到令牌过期或被撤销。
授权类型：资源所有者密码凭据
与资源所有者密码凭据授权类型，用户提供他们的服务凭据（用户名和密码）直接连接到应用程序，它使用这些凭据获得服务的访问令牌。 只有在其他流不可行时，才能在授权服务器上启用此授权类型。 此外，它应该仅在应用程序受用户信任时使用（例如，它由服务或用户的桌面操作系统拥有）。
密码凭据流
在用户将其凭证提供给应用程序之后，应用程序然后将从授权服务器请求访问令牌。 POST请求可能如下所示：
https://oauth.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID
如果用户凭证签出，授权服务器会向应用程序返回一个访问令牌。 现在应用程序已授权！
注：DigitalOcean目前不支持密码凭据授予的类型，所以在“oauth.example.com”的链接指向一个假想的授权服务器。
授权类型：客户端凭据
客户端证书授予类型提供一个应用程序的方式来访问自己的服务帐户。 当这可能有用时的示例包括：如果应用程序想要更新其注册的描述或重定向URI，或者通过API访问存储在其服务帐户中的其他数据。
客户机凭据流
应用程序通过将其凭证，其客户端ID和客户端密钥发送到授权服务器来请求访问令牌。 示例POST请求可能如下所示：
https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET
如果应用程序凭证签出，授权服务器会向应用程序返回访问令牌。 现在应用程序有权使用自己的帐户！
注：DigitalOcean目前不支持客户端证书授予的类型，所以在“oauth.example.com”的链接指向一个假想的授权服务器。
示例访问令牌使用
一旦应用具有访问令牌，它可以使用令牌通过API访问用户的账户，限于访问范围，直到令牌过期或被撤销。
这里是使用API请求的一个例子， curl 。 请注意，它包括访问令牌：
curl -X POST -H "Authorization: Bearer ACCESS_TOKEN""https://api.digitalocean.com/v2/$OBJECT"
假设访问令牌有效，API将根据其API规范处理请求。 如果访问令牌过期或无效，API将返回“invalid_request”错误。
刷新令牌流
访问令牌过期后，使用它从API发出请求将导致“无效的令牌错误”。 此时，如果在发布初始访问令牌时包括刷新令牌，则可以使用刷新令牌从授权服务器请求新的访问令牌。
以下是一个示例POST请求，使用刷新令牌获取新的访问令牌：
https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN
结论
本OAuth 2指南的最后。 您现在应该了解OAuth 2的工作原理，以及何时应使用特定的授权流程。
如果您想详细了解OAuth 2，请查看以下宝贵资源：
