OAuth 2.0初学者指南

本文概述了OAuth 2.0协议。它讨论了OAuth 2.0实现过程中涉及的不同参与者和步骤。

介绍：

OAuth代表开放授权。它是一个免费开放的协议，建立在IETF标准和Open Web Foundation的许可之上。它允许用户与第三方共享其私有资源，同时保密自己的凭据。这些资源可以是照片，视频，联系人列表，位置和计费功能等，并且通常与其他服务提供商一起存储。OAuth通过在用户批准访问权限时向请求（客户端）应用程序授予令牌来执行此操作。每个令牌在特定时间段内授予对特定资源的有限访问权限。

1. Oauth2是一个授权协议：

OAuth2支持“委派身份验证”，即授予对其他人或应用程序的访问权限以代表您执行操作。考虑一下这种情况：你开车去一家优雅的酒店，他们可能会提供代客泊车服务。然后，您授权代客服务员通过将钥匙交给他来开车，以便让他代表您执行操作。

OAuth2的工作方式类似 - 用户授予对应用程序的访问权限，以代表用户执行有限的操作，并在访问可疑时撤消访问权限。

2.参与OAuth2的参与者：

i）资源服务器：托管受OAuth2保护的用户拥有资源的服务器。资源服务器验证访问令牌并提供受保护资源。

ii）资源所有者：通常，应用程序的用户是资源所有者。资源所有者能够授予或拒绝访问资源服务器上托管的自己的数据。

iii）授权服务器：授权服务器获得资源所有者的同意，并向客户端发出访问令牌以访问资源服务器托管的受保护资源。

iv）客户端：应用程序使API请求代表资源所有者对受保护资源执行操作。在它可以这样做之前，它必须由资源所有者授权，并且授权必须由资源服务器/授权服务器验证。OAuth2根据其与授权服务器安全身份验证的能力（即，维护其客户端凭据机密性的能力）定义了两种客户端类型：

a）机密：客户能够保持其凭证的机密性。机密客户端在安全服务器上实现，具有对客户端凭证的受限访问（例如，在Web服务器上运行的Web应用程序）。

b）公共：客户端无法维护其凭据的机密性（例如，已安装的本机应用程序或基于Web浏览器的应用程序），并且无法通过任何其他方式进行安全的客户端身份验证。

3.您是应用程序开发人员，这是一个用例：

考虑一个场景。您正在开发一个有趣的Facebook应用程序，并将其称为“FunApp”。FunApp需要访问用户的公开个人资料，照片，帖子，朋友等。现在问题是，FunApp如何获得用户从Facebook访问他/她的数据的权限，同时告知Facebook用户已授予此权限FunApp使Facebook能够与这个应用程序共享用户的数据？

旧方式：用户与FunApp共享他/她的Facebook凭据（用户名，密码）。这种方法存在一些挑战：信任，不受限制的访问，用户对Facebook密码的更改等。

OAuth2方式：如果应用需要访问其用户数据，Funapp会将用户重定向到Facebook上的授权页面。用户将登录其帐户并授予访问权限，然后FunApp将从Facebook获取访问令牌以访问用户的数据。虽然Oauth2已经解决了这些挑战，但它也为开发人员创造了成本。

让我们从开发人员的角度看这个场景，并找出这里涉及的演员：

• 由于Facebook拥有所有资源（用户的公开个人资料，照片，帖子，朋友等），因此它成为资源服务器。
• 用户是资源所有者。
• 当FunApp请求用户的受保护资源时，它将成为客户端。
• 当Facebook获得用户同意并向FunApp发出访问令牌时，它将成为授权服务器。

4.注册客户端（FunApp）和获取客户端凭据：

OAuth要求客户端向授权服务器注册。授权服务器请求有关客户端的一些基本信息，例如name，redirect_uri（授权服务器在资源所有者授予权限时将重定向到的URL）并将客户端凭据（client-id，client-secret）返回给客户端。在执行诸如交换访问令牌的授权码和刷新访问令牌等操作时，这些凭证对于保护请求的真实性至关重要。

例如，Facebook要求您在Facebook Developers门户网站上注册您的客户端。转到Facebook开发人员门户网站并注册FunApp并获取客户端凭据。

5.逐步获取访问令牌：

FunApp需要从Facebook获取访问令牌才能访问用户的数据。为了获得访问令牌，FunApp将用户重定向到Facebook的登录页面。成功登录后，Facebook会重定向到redirect_uri（在步骤4中注册）以及短期授权代码。FunApp交换授权代码以获取长期访问令牌。访问令牌用于访问用户的数据。这是OAuth2中最受欢迎的流程，称为授权代码授权。以下是在授权代码授权中获取访问令牌的序列图：

6. 了解授权授权类型：

要获取访问令牌，客户端将从资源所有者获取授权。授权以授权授权的形式表示，客户端使用该授权授权来请求访问令牌。OAuth2定义了四种标准授权类型：授权代码，隐式，资源所有者密码凭据和客户端凭据。它还提供了一种用于定义其他授权类型的扩展机制。

i）授权代码授权：此授权类型针对机密客户端（Web应用程序服务器）进行了优化。授权代码流不会将访问令牌公开给资源所有者的浏览器。相反，使用通过浏览器传递的中间“授权代码”来完成授权。在对受保护的API进行调用之前，必须将此代码交换为访问令牌。

ii）隐性拨款：此拨款类型适用于公共客户。隐式授权流程不适用刷新令牌。如果授权服务器定期过期访问令牌，则只要需要访问权限，您的应用程序就需要运行授权流程。在此流程中，在用户授予所请求的授权后，会立即将访问令牌返回给客户端。不需要中间授权代码，因为它在授权代码授权中。

iii）资源所有者密码凭证：资源所有者密码凭证授权类型适用于资源所有者与客户端具有信任关系并且资源所有者同意与客户端共享他/她的凭证（用户名，密码）的情况。然后，客户端可以使用所有者凭据中的资源从授权服务器获取访问令牌。

iv）客户端凭据：当客户端本身拥有数据且不需要资源所有者的委派访问权限，或者已经在典型OAuth流程之外授予应用程序委派访问权限时，此授权类型是合适的。在此流程中，不涉及用户同意。客户端交换其客户端凭据以获取访问令牌。

7.令牌已过期，获取新的访问令牌：

如果访问令牌由于令牌已过期或已被撤销而不再有效，则使用OAuth 2.0访问令牌进行API调用可能会遇到错误。在这种情况下，资源服务器将返回4xx错误代码。客户端可以使用刷新令牌（在授权代码交换访问令牌时获得）获取新的访问令牌。

8.结论：

这是尝试提供OAuth 2.0过程的概述，并提供获取访问令牌的方法。我希望它有所帮助。

享受整合应用的乐趣！

英文原文：dzone.com/articles/oa…