[.com原稿]在互联网飞速发展的今天，互联网应用层出不穷，每一个应用侧重于不同的领域和方法。图片来自宝途网为了给用户提供更好的体验，一个互联网应用会请求用户对另一个应用进行授权。获得授权后，可以获取其他应用的资源，更好的为用户服务。OAuth2.0是一种帮助用户授权新的第三方应用程序的协议。今天给大家介绍一下OAuth2.0的实现原理和协议授权规范。包括以下内容：从一个简单的例子理解OAuthOAuth2.0的定义和构成OAuth2.0的RefreshTokenOAuth2.0的授权模式从一个简单的例子理解OAuth在介绍OAuth2.0之前，我们先来看一个简单的例子。假设你平时喜欢拍照，把生活中的点点滴滴记录成电子照片存储在云盘上，每隔一段时间就会选择自己喜欢的照片打印保存。同时，你发现网上有一款云打印照片的应用。您只需导入电子照片，本应用即可为您打印并邮寄到您家。我们将本例中的授权部分提取出来形成图1，如图1所示，左边部分是云打印部分，也就是我们需要使用的互联网服务。右边绿色部分为用户，即电子照片的资源拥有者。图1：云打印服务的授权流程云盘需要提供两种服务，一种是授权服务，即照片所有者授权第三方应用使用照片资源，另一个是资源服务本身，即照片资源的提供者。通过图1的展示，我们将请求云打印服务和授权的整个过程分为以下几个步骤：用户请求云打印服务。此时应用只是简单的请求服务，并不向云打印服务提供电子照片资源。.云打印服务收到请求后，由于没有电子相片云盘的访问权限，要求用户对云盘进行授权。为实现云打印服务，用户授权云打印访问云盘中的电子照片。云打印将用户的授权通知给云盘中的授权服务。当授权服务得知用户授权云打印服务打印用户在云盘中的照片时，将访问权限返回给云打印服务。获得图片资源访问权限的云打印服务可以使用该访问权限访问云盘中的电子图片资源。云盘资源服务收到访问权限请求后，返回电子照片，云打印服务启动打印服务。OAuth2.0的定义和组成从上面的小例子可以发现，当用户访问第三方网络应用（云打印）时，需要授权云打印才能访问云盘资源。授权后，云盘的授权服务会返回云打印应有的权限。请注意，它不会将所有云盘权限返回给云打印。例如：电子照片的增删改查，根据用户的授权，只授予云打印部分权限，即获取电子照片的权限。为什么要走这个授权流程可以分析如下：用户为了打印照片，将访问云盘的用户名和密码交给云打印服务，显然是不安全的。云打印在用户云盘授权时，并不是获取全部权限，而是获取部分权限。该权限仅针对电子照片的访问权限，一般情况下还可以设置该权限的访问时长，例如：2小时或1天，以保证打印服务的正常运行。如果此时云打印通过知道用户名和密码的方式访问云盘，云打印的系统就会被黑，从而导致云盘的资源泄露。鉴于以上三点的分析，我们需要使用OAuth进行授权。OAuth认证是让第三方应用程序在不获取用户敏感信息（如账号密码、用户密码等）的情况下，允许用户授权其访问开放平台中的资源接口。之所以使用OAuth2.0，是因为OAuth1.0协议过于复杂，易用性差，难以普及。OAuth2.0是通过一个新的协议设计的，更容易使用，更容易普及。了解了OAuth2.0协议的设计目的之后，我们再来看看它的组成部分。映射上一节中提到的示例将其分解为4个组件。图2：OAuth2.0的执行流程如图2：客户端：作为访问应用的客户端，即需要授权才能访问资源的应用，本例中为第三方应用（云印刷）。ResourceOwner：资源所有者，示例中的用户，可以授予第三方应用程序（云打印），即Client，一个对受保护资源具有访问权限的实体。AuthorizationServer：授权服务器，其作用是在ResourceOwner对Client进行认证授权后，通过AuthorizationServer向Client颁发访问令牌。ResourceServer：资源服务器，用于存储资源，示例中为存储电子照片，当Client使用token访问时，会接受响应并返回受ResourceOwner保护的资源，即电子照片。其中，AuthorizationServer和ResourceServer可以分开，也可以存在于同一台服务器上。根据上面的例子，两部分都属于云盘服务器。上面介绍了OAuth2.0的几个组件，这里我们就图2中的执行流程进行说明：客户端（Client）向资源拥有者（ResourceOwner）请求授权。客户端（Client）收到用户授权，即代表资源拥有者（ResourceOwner）授权的凭证（Authorization）。客户端（Client）通过向授权服务器（AuthorizationServer）进行认证并提供授权许可，请求访问令牌（AccessToken）。授权服务器（AuthorizationServer）对客户端进行认证并验证授权许可，如果有效则颁发访问令牌（AccessToken）。客户端（Client）向资源服务器（ResourceServer）请求受保护的资源，并通过提供访问令牌（AccessToken）进行身份验证。资源服务器验证访问令牌，如果有效，则为请求提供服务。通过以上过程，Client最终可以获取到ResourceServer上的资源，为ResourceOwner提供相应的服务。这整个过程称为授权，代表资源所有者（ResourceOwner）授权客户端（Client）访问其受保护的资源，以及客户端获得访问令牌的整个过程。OAuth2.0的RefreshToken说资源服务器（ResourceServer）通过验证客户端（Client）访问令牌（AccessToken）来提供资源服务，所以访问令牌（AccessToken）是访问受保护资源的凭证。它是授权服务器（AuthorizationServer）客户端（Client）下发的字符串，规定了资源访问的范围和持续时间。正因为如此，访问令牌（AccessToken）在超出范围时就会失效，尤其是在超过访问时间的时候。这时，客户端需要额外获取一个访问令牌（AccessToken）。这时授权服务器会向客户端颁发一个刷新令牌（RefreshToken）。与访问令牌（AccessToken）不同的是，刷新令牌（RefreshToken）只用于授权服务器，从不发送给资源服务器。在后面提到的授权码方式中，授权服务器会同时返回一个刷新令牌（RefreshToken）。其目的是在访问令牌（AccessToken）过期前重新获取新的访问令牌（AccessToken），无需资源拥有者（ResourceOwner）重新确认授权，提高了授权效率和用户体验。在访问令牌（AccessToken）之前，客户端（Client）可以使用刷新令牌（RefreshToken）向授权服务器（AuthorizationServer）发送请求。图3如图3所示，假设b.com为AuthorizationServer地址，请求中包含以下内容：Receivedgrant_type：授权类型，值为'refresh_token'。client_id：客户端id，即在授权服务器上注册的客户端（Client）分配的id。client_secret：客户端（Client）和授权服务器（AuthorizationServer）使用的密钥，由授权服务器颁发，在需要特殊确认时用作验证条件。refresh_token：用户获取新access_token的refresh_token。OAuth2.0的授权模式介绍了OAuth2.0的定义和组成结构，详细描述了其授权过程，并提出了AccessToken过期时RefreshToken的解决方案。接下来介绍OAuth2.0的授权模式，即资源拥有者将资源使用权限授予客户端的方式。这里有4种授权模式，分别是：AuthorizationCodeModeImpliedAuthorizationModePasswordModeClientMode①授权码模式（AuthorizationCode）是功能最全、流程最严格的授权模式，其特点是通过后台客户端服务器，它与“服务提供商”的身份验证服务器交互。授权码方式使用访问令牌（AccessToken）和刷新令牌（RefreshToken）两种，授权过程基于重定向的流程。客户端（Client）可以接收来自资源所有者的用户代理（UserAgent）的传入请求。然后通过重置URI发送给授权服务器（AuthorizationServer），得到返回的访??问令牌（AccessToken）。图4：授权码模式流程图如图4所示。这里，授权码模式的流程分为5个步骤：客户端（Client）初始化流程，资源对应的用户代理（UserAgentbrowser）owner指向授权服务器。此时，客户端（Client）包含了自己的ID、请求范围、本地状态和重定向的URI信息。这个URI就是告诉AuthorizationServer在授权完成之后回调给UserAgent的URI。用户代理将用户的身份信息发送给授权服务器。授权服务器（AuthorizationServer）会验证资源拥有者（ResourceOwner）的身份，然后返回授权结果。假设授权服务器（AuthorizationServer）通过了资源拥有者的授权，它会通过用户代理通过重定向URI返回授权码（AuthorizationCode）和一些状态信息给客户端（Client）。客户端收到授权码（AuthorizationCode），附加重定向的URI向授权服务器（AuthorizationServer）申请访问令牌（AccessToken）。同时会附加重定向的URI，返回访问令牌（AccessToken）时可以找到对应的客户端（Client）。认证服务器（AuthorizationServer）检查授权码（AuthorizationCode）并确认无误后，通过重定向的URI向客户端发送访问令牌（AccessToken）和更新令牌（RefreshToken）。下面的过程是客户端使用访问令牌（AccessToken）访问资源服务器（ResourceServer）。通过上面对授权码模式的介绍，我们不仅会问一个问题，客户端为什么要从授权服务器获取授权呢？然后用这个授权码向授权服务器申请accesstoken，授权服务器直接把accesstoken发送给客户端，是不是很快就发完了？不是要一下子绕个大圈吗？其原因解释如下：用户代理在显示中以浏览器的形式存在，浏览器中对应的浏览器重定向URI（redirect_uri）被认为是不安全的通道，这种方式不适合敏感数据的传输-访问令牌。因为URI可能会通过HTTPreferrer传递给其他恶意站点，也可能存在于浏览器缓存或日志文件中，为攻击者窃取访问令牌提供了便利。这里的另一个假设是，虽然资源所有者的行为是值得信任的，但是资源所有者使用的用户代理，即浏览器，可能已经被攻击者植入了跨站脚本以监听访问令牌。此时将访问令牌用户代理传递给客户端会增加访问令牌被泄露的风险。但是授权码（AuthorizationCode）可以通过重定向URI传递。授权代码不如访问令牌敏感。即使授权码泄露，攻击者也无法直接获取访问令牌来访问资源。因为在拿到授权码交换accesstoken的时候，需要验证客户端的真实身份。说白了，除了客户端，其他人使用授权码是没有用的。这也是accesstoken只能发给client的原因，其他任何主体，包括资源拥有者，都不应该获得accesstoken。该协议的设计保证了客户端是唯一能够获得访问令牌的主体。引入授权码的目的也是为了保证客户端是accesstoken的唯一持有者。另外，由于协议需要验证客户端的身份，如果不引入授权码，客户端的身份认证只能通过重定向URI。由于重定向URI是一个不安全的通道，因此额外要求客户端必须使用数字签名技术进行身份认证，而不是简单的口令或密码认证。引入授权码后，授权服务器可以直接对客户端进行认证，支持任何客户端认证方式。可以理解为授权码作为客户端和资源拥有者之间的中介，验证客户端的身份。②隐式授权模式（ImplicitGrant）是一种简化模式。因为之前的模式需要用授权码交换accesstoken来实现授权，在提高安全性的同时增加了复杂度。因此，隐式授权模式会在用户代理（浏览器）中直接向授权服务器申请一个accesstoken，跳过授权码这一步，所有步骤都在浏览器中完成，accesstoken对访问者可见，并且客户端不需要身份验证。图5：隐式授权模式的流程图如图5所示，我们看一下隐式授权模式的执行过程：客户端（Client）初始化过程，资源对应的用户代理（UserAgentbrowser）owner指向授权服务器。此时，客户端（Client）包含了自己的ID、请求范围、本地状态和重定向的URI信息。这个URI就是告诉AuthorizationServer在授权完成之后回调给UserAgent的URI。用户代理（UserAgent）将用户的身份信息发送给授权服务器（AuthorizationServer），授权服务器（AuthorizationServer）对资源所有者（ResourceOwner）进行身份验证，然后返回结果的授权。假设授权服务器（AuthorizationServer）通过了资源拥有者的授权，它将使用重定向URI通过用户代理返回访问令牌（accesstoken）给客户端（Client）。用户代理通过重定向的URI定向到Web上托管的客户端资源。Web托管的客户端资源返回一个网页，这是一个带有脚本脚本的HTML文档，其中包含一个可以访问所有资源的访问令牌（AccessToken）。用户代理（UserAgent）也就是浏览器。收到返回的Script后，从中提取需要的访问令牌（AccessToken）。然后用户代理（UserAgent）将访问令牌（AccessToken）传递给客户端（Client），继续后续的资源获取工作。如上所述，隐式授权方式简化了获取授权码的过程。虚拟主机客户端资源返回的script脚本携带相应的访问码，用户代理提取访问码后返回给客户端调用资源。这种方式虽然省去了获取授权码的过程，但是将访问码存储在用户代理中存在一定的安全隐患。③密码方式（ResourceOwnerPasswordCredentialsGrant）用户向客户端提供自己的用户名和密码。客户端使用此信息向授权服务器请求授权。在这种模式下，用户必须将自己的密码提供给客户端，但客户端不能存储密码。这通常只有在用户对客户端有高度信任的情况下才会这样做，例如客户端是操作系统的一部分，或者是由知名公司生产的。认证服务器只有在无法实现其他授权方式的情况下，才能考虑使用该方式。图6：密码模式流程图接下来我们看一下密码模式的执行过程，如图6所示，整个过程比较简单，分为3个步骤：资源拥有者提供用户名和密码给client从所有者处获得的授权（用户名+密码）发送给授权服务器，以获得访问资源服务器的权限。授权服务器在确认资源所有者的授权（用户名+密码）后，返回访问令牌和刷新令牌。④客户端模式（ClientCredentialsGrant）是指客户端以自己的名义向授权服务器进行认证，而不是以用户的名义。这种模式下，用户直接向客户端注册，客户端请求授权服务器以自己的名义提供服务，不存在授权问题。这种模式完全超出了OAuth2.0模式的范围，因为资源所有者没有授权行为。只有当客户端在授权服务器上拥有可控资源时，才能使用该方法。图7：客户端模式的流程图如图7所示。该模式分为2步：客户端自己向授权服务器发起授权请求，申请访问令牌。授权服务器在身份验证和授权后向客户端发送访问令牌。总结本文以云打印照片为例，通过用户授权云打印服务访问云盘获取电子照片的全过程，带出OAuth2.0实现的资源授权和访问功能。然后提出OAuth2.0是一种协议，用于保证授权访问资源的第三方应用程序的安全性。该协议涉及客户端、资源所有者、授权服务器和资源服务器，描述了授权过程如何在它们之间展开。介绍完授权过程，进一步说明accesstoken只能在访问资源的过程中获取。如果token过期，需要通过刷新token来维护授权的有效性。最后介绍了OAuth2.0的四种授权模式，即授权码模式、隐式授权模式、密码模式和客户端模式，以及它们的实现过程。【原创稿件，合作网站转载请注明原作者和出处为.com】
