简而言之，OAuth 2.0

假设您正在开发一个SOA应用程序。用户界面是一个需要从公共互联网访问的网站。您在UI中使用服务组合，因此在UI中部署了每个服务的JavaScript组件。这些组件通过HTTP与相应的Web API进行通信。由于Web API是面向公众的，它们位于DMZ中，因此您需要保护它们。在本系列博客文章中，我想对事实上的授权标准OAuth 2.0和新兴的联合身份验证标准OpenID Connect进行一个高级别的概述。

身份验证和授权

首先，让我们定义身份验证和授权的含义：

身份验证是我们验证某人是否为其自称的人的过程。通常，您可以通过提供以下至少一个因素进行身份验证：

• 你知道的东西--密码或密码
• 您拥有的东西–-证书或RSA令牌
• 你是什么样的人--指印

授权是我们检查某人拥有的权限的过程。尽管这可以用多种方式建模，但它可以被视为一个矩阵，每行有主题，每列有资源，单元格中有动作。

OAuth 2.0

如果我们讨论的是API授权，我们还需要讨论委托访问模型。最终用户将其在API网站上托管的资源的访问权委托给客户——网站。如果我们不想将用户的凭据传递给客户端和API，那么OAuth是一个不错的选择。OAuth是一种授权协议，可用于为第三方应用程序实现对私有资源的有限访问。

Actors

以下是OAuth协议定义的主要角色：

• 顾名思义，资源所有者是私有资源的所有者，这意味着他可以授予访问权限。很多时候，资源所有者就是最终用户。
• 资源服务器承载资源。如果我们谈论的是保护web API，那就是您的资源服务器。
• 客户端是希望代表所有者对资源执行操作的应用程序。使用web API数据的网站就是客户端的一个很好的例子。
• 授权服务器在资源所有者的批准下向客户端授予对受保护资源的访问权限。

Tokens

由于OAuth的目的是使资源所有者能够在不共享其凭据的情况下授予对其资源的访问权限，因此OAuth使用基于令牌的授权。令牌是由授权服务器发布并由客户端用于将请求与资源所有者相关联的唯一标识符。

访问令牌

OAuth 2.0依赖于访问令牌，该令牌向客户端授予代表资源所有者访问受保护资源的权限。访问令牌通常有一个到期日期和一个范围——客户端可以对资源执行哪些操作（例如读取或写入）。除了授权服务器之外，我应该对任何人都是不透明的——这意味着即使它可能包含有意义的数据，你也不应该试图解释它。访问令牌也可能有受众，这意味着该令牌是为特定客户端颁发的，它可以用于特定的资源服务器集。

令牌类型是OAuth 2.0的可扩展点之一，因为您可以定义自己的令牌类型。OAuth 2.0定义了两个主要的令牌配置文件：承载令牌配置文件和MAC（消息验证码）令牌配置文件。

不记名代币就像现金——任何拥有它的人都可以使用它。另一方面，MAC代币就像信用卡——为了使用它，你需要用你的签名授权它。您永远不会通过有线传输MAC令牌，而需要传输承载令牌。这意味着您始终需要将TLS与承载令牌一起使用。因为实现MAC令牌配置文件更加困难，所以大多数OAuth 2.0实现都使用承载令牌配置文件。

刷新令牌

OAuth还定义了一个可选的刷新令牌。这可以用于获得新的访问令牌。与访问令牌的寿命相比，刷新令牌的寿命要长得多。这意味着，如果访问令牌被泄露，攻击者可以在有限的时间内使用它（通常以分钟为单位）。

代客泊车类比 （The Valet Parking Analogy）

Eran Hammer使用了代客泊车的比喻来解释OAuth的目的。如今，许多昂贵的汽车都有一把额外的钥匙，称为代客钥匙，这让你只能有限地进入汽车：你只能行驶有限的距离，而且你不能打开手套箱或汽车的后备箱。这就是OAuth的作用：当你（资源所有者）开车（受保护的资源）去酒店，代客泊车服务员（OAuth客户）想停车时，你不想把你的主密钥（用户名和密码）交给他，这会让他无限量地访问你的车。所以你给他代客钥匙（通行证），这让他非常有限地进入汽车，这样他就可以停车了。

登记

OAuth要求客户端注册到授权服务器，以便它能够识别有效的API请求。客户端注册后，将收到一个公开的客户端ID和一个应保密的客户端机密。

授权流程

OAuth 2.0引入了授权授予的概念。授权代表资源所有者的批准，它可以交换为访问代码。授权授予是OAuth 2.0的另一个扩展点，因为它允许多种类型的客户端使用该协议。OAuth 2.0定义了4种主要授予类型：授权代码、隐式授予、资源所有者密码凭据和客户端凭据。

授权代码授予

授权代码（或服务器端流）是为服务器应用程序设计的。在获得资源所有者的批准后，授权服务器通过查询字符串参数向客户端返回授权代码。然后，使用客户端ID和客户端机密，客户端可以通过服务器端调用将授权码交换为访问令牌。这意味着访问令牌永远不会透露给资源所有者，这确保了访问令牌的机密性，并且访问令牌不太可能被浏览器中的恶意JavaScript代码劫持。

这种授予类型也可以用于颁发刷新令牌，因此在需要长期访问时非常适合。这意味着客户端应用程序将存储刷新令牌，这可能会使其更容易受到攻击。

隐性授予

隐式授予类型是为客户端应用程序设计的，比如在浏览器中运行的JavaScript应用程序。由于整个应用程序代码都是可访问的，因此客户端机密不能存储在应用程序中。这就是为什么在第一步中资源所有者授权客户端后，访问令牌会立即通过哈希代码URL片段返回。此流不支持刷新令牌，因此您需要在其过期后请求新的访问令牌。

资源所有者密码凭证授予 (Resource Owner Password Credentials Grant)

在此流程中，资源所有者将其用户名和密码传递给授权服务器，以换取访问令牌。由于客户端必须知道用户的密码，因此建议仅在高度可信的客户端（如官方移动应用程序）中实现此流程。

客户端凭据授予（Client Credentials Grant）

在这个流程中，客户端是资源所有者。他必须通过凭据才能检索访问令牌。当客户端（通常是API）需要访问他拥有的资源（如数据库或存储服务）时，应使用此授予类型。

终点

端点只是一个HTTP资源，用作授权流的一部分。OAuth定义了3个端点：2个授权服务器端点——授权端点和令牌端点，1个客户端端点——重定向端点。

授权端点用于与资源所有者交互并检索客户端的授权授予（代码）。此终结点必须确保客户端经过身份验证。

令牌端点用于将授权授予交换为访问令牌。它用于所有流，但隐式流除外，隐式流直接从授权端点发出访问令牌。

重定向端点用于将资源所有者的浏览器重定向回客户端应用程序。令牌还通过查询字符串参数或哈希代码URL片段传递给客户端。

配置文件

可以通过实现自定义授予类型和/或令牌类型来扩展OAuth 2.0。以下是一些构建在核心框架之上的概要文件，以适应新的用例：

• SAML2.0承载断言配置文件用于交换访问令牌的SAML断言。当组织已经使用SAML进行联合身份验证时，这在企业场景中非常有用。
• 用户管理的访问配置文件使资源所有者能够在一个位置（即授权服务器）为其受保护的资源定义和管理多个访问策略。
• 链授权类型简档使资源服务能够使用所接收的访问令牌，并以链的方式充当另一资源服务的客户端。
• Token Introspection Profile允许客户端请求有关令牌的元数据，例如，以查明令牌是否已过期或其受众是什么。
• 令牌吊销配置文件可用于吊销令牌。
• 动态客户端注册配置文件允许客户端向授权服务器注册，并动态检索其客户端ID和机密。

OAuth 1.0与OAuth 2.0

OAuth 2.0不是OAuth 1.0的升级版。事实上，它们在概念层面上有很大的不同。

OAuth 1.0是一种具体的安全协议，它依赖于签名来提供高度的安全性。这使得OAuth 1.0成为一个很难实现的复杂协议。此外，OAuth 1.0没有达到很高的采用率，因为它不可扩展——它提供了一个旨在容纳所有客户端配置文件的单一流。

OAuth 2.0是一个安全框架，因此，从定义上讲，它是可扩展的。它的两个主要扩展点是授权类型和令牌类型。此外，OAuth 2.0放弃了签名和加密的使用，并依赖TLS来保护传输中的数据，这使其依赖于传输。OAuth 2.0牺牲了安全性来实现可扩展性和易实现性。Eran Hammer辞去了OAuth 2.0规范的主要作者和编辑的职务，并不同意为OAuth 2.0做出的设计决定。

结论

OAuth 2.0是API安全性的事实标准。您现在应该了解这个框架的基本知识，以及何时应该使用特定的授权流。在下一篇博客文章中，我们将讨论通过OpenIDConnect进行身份验证的问题。

如果您想了解更多关于OAuth 2.0的信息，可以查看以下资源：

• Getting Started with OAuth 2.0 by Ryan Boyd
• Advanced API Security: Securing APIs with OAuth 2.0, OpenID Connect, JWS, and JWE by Prabath Siriwardena
• OAuth 2.0 Specs
• OAuth 2.0 Security