附录B OAuth2受权类型

    本附录主要内容

    OAuth2密码受权（password grant）

    OAuth2客户端凭据受权（client credentials grant）

    OAuth2鉴权码受权（authorization code grant）

    OAuth2隐式受权（implicit grant）

    OAuth2令牌刷新

 

在阅读第7章时，读者可能会认为OAuth2看起来不太复杂。毕竟有一个验证服务，用于检查用户的凭据并颁发令牌给用户。每次用户想要调用由OAuth2服务器保护的服务时，均可以依次出示令牌。

    遗憾的是，现实世界历来都不是简单的。因为Web应用程序和基于云的应用程序具备相互关联的性质，用户指望能够安全地共享本身的数据，并在不一样服务所拥有的不一样应用程序之间整合功能。这从安全角度来看，是一个独特的挑战，由于开发人员但愿跨不一样的应用程序进行整合，而不是强迫用户与他们想要集成的每一个应用程序共享他们的凭据。

    幸运的是，OAuth2是一个灵活的受权框架，它为应用程序提供了多种机制来对用户进行验证和受权，而不用强制他们共享凭据。可是，这也是OAuth2被认为是复杂的缘由之一。这些验证机制被称为验证受权（authentication grant）。OAuth2有4种模式的验证受权，客户端应用程序可使用它们来对用户进行验证、接收访问令牌，而后确认该令牌。这些受权分别是：

    密码受权；

    客户端凭据受权；

    受权码受权；

    隐式受权。

    在下面几节中，我将介绍在执行每一个OAuth2受权流程期间发生的活动，同时我会谈到什么时候适合使用何用受权类型。

 

B.1　密码受权

    OAuth2密码受权多是最容易理解的受权类型。这种受权类型适用于应用程序和服务都明确相互信任的时候。例如，EagleEye Web应用程序和EagleEye Web服务（许可证服务和组织服务）都由ThoughtMechanix拥有，因此它们之间存在着一种自然的信任关系。

    注意

    

    明确地说，当我提到“自然的信任关系”时，个人意思是应用程序和服务彻底由同一个组织拥有，而且它们是按照相同的策略和程序来管理的。

    当存在一种自然的信任关系时，几乎不用担忧将OAuth2访问令牌暴露给调用应用程序。例如，EagleEye Web应用程序可使用OAuth2密码受权来捕获用户凭据，并直接针对EagleEye OAuth2服务进行验证。图B-1展现了EagleEye和下游服务之间的密码受权。

 

图B-1　OAuth2服务肯定访问服务的用户是否为已经过验证的用户

    在图B-1中，正在发生如下活动。

    （1）在EagleEye应用程序可使用受保护资源以前，它须要在OAuth2服务中被惟一标识。一般，应用程序的全部者经过OAuth2服务进行注册，并为其应用程序提供惟一的名称。OAuth2服务随后提供一个密钥给正在注册的应用程序。

    应用程序的名称和由OAuth2服务提供的密钥惟一地标识了试图访问任何受保护资源的应用程序。

    （2）用户登陆到EagleEye，并将其登陆凭据提供给EagleEye应用程序。EagleEye将用户凭据以及应用程序名称、应用程序密钥直接传给EagleEye OAuth2服务。

    （3）EagleEye OAuth2服务对应用程序和用户进行验证，而后向用户提供OAuth2访问令牌。

    （4）每次EagleEye应用程序表明用户调用服务时，它都会传递OAuth2服务器提供的访问令牌。

    （5）当一个受保护的服务（在本例中是许可证服务和组织服务）被调用时，该服务将回调到EagleEye OAuth2服务来确认令牌。若是令牌是有效的，则被调用的服务容许用户继续进行操做。若是令牌无效，OAuth2服务将返回HTTP状态码403，指示该令牌无效。

 

B.2　客户端凭据受权

    当应用程序须要访问受OAuth2保护的资源时，一般会使用客户端凭据受权，但在这个事务中不涉及任何人员。使用客户端凭据受权类型，OAuth2服务器仅根据应用程序名称和资源全部者提供的密钥进行验证。一样，客户端凭据受权常常用于两个应用程序都归同一个公司全部时。密码受权和客户端凭据受权的区别在于，客户端凭据受权仅使用注册的应用程序名称和密钥进行验证。

    例如，假设EagleEye应用程序每隔一小时就会运行一个数据分析做业。做为其工做的一部分，它向EagleEye服务发出调用。可是，EagleEye开发人员仍然但愿应用程序在访问这些服务中的数据以前，进行验证和鉴权。这是可使用客户端凭据受权的场景。图B-2展现了这个流程。

 

但愿应用程序在访问这些服务中的数据以前，进行验证和鉴权。这是可使用客户端凭据受权的场景。图B-2展现了这个流程。

 

图B-2　客户端凭据受权适用于“无用户参与”的应用程序验证和受权

    （1）资源全部者经过OAuth2服务注册了EagleEye数据分析应用程序。资源全部者将提供应用程序的名称并接收一个密钥。

    （2）当EagleEye数据分析做业运行时，它将出示应用程序名称和资源全部者提供的密钥。

    （3）EagleEye OAuth2服务将使用提供的应用程序名称和密钥对应用程序进行验证，而后返回一个OAuth2访问令牌。

    （4）每当应用程序调用EagleEye服务时，它就会出示它在OAuth2服务调用中接收到的OAuth2访问令牌。

 

B.3　鉴权码受权

    受权码受权是迄今为止最复杂的OAuth2受权，但它也是最经常使用的流程，由于它容许来自不一样供应商的不一样应用程序共享数据和服务，而无须在多个应用程序间暴露用户凭据。鉴权码受权不会让调用应用程序当即得到OAuth2访问令牌，而是使用一个“预访问”受权码的方式来执行额外的检查。

    理解受权码受权的简单方法就是看一个例子。假设有一个EagleEye用户，它也使用 Salesforce.com。EagleEye客户的IT部门已经构建了一个Salesforce应用程序，它须要EagleEye服务（组织服务）的数据。来看一下图B-3，看看受权码受权是如何使Salesforce从EagleEye的组织服务中访问数据而无须EagleEye客户向Salesforce公开他们的EagleEye凭据的。

图B-3　受权码受权可让应用程序在不暴露用户凭据的状况下共享数据

    （1）EagleEye用户登陆到EagleEye，并为其Salesforce应用程序生成应用程序名称和应用程序密钥。做为注册过程的一部分，还将提供一个回调URL，以返回到基于Salesforce的应用程序。此回调URL是一个Salesforce的URL，将在EagleEye OAuth2服务器验证了用户的EagleEye凭据后被调用。

 

（2）用户使用如下信息配置Salesforce应用程序：

    为Salesforce建立的应用程序名称；

    为Salesforce生成的密钥；

    指向EagleEye OAuth2登陆页面的URL。

    如今，当用户尝试使用Salesforce应用程序并经过组织服务访问EagleEye数据时，根据上述要点中描述的URL，用户将被重定向到EagleEye登陆页面。用户将提供他们的EagleEye凭据。若是提供的EagleEye凭据有效，则EagleEye OAuth2服务器将生成一个受权码，并经过步骤1中提供的URL将用户重定向到Salesforce。受权码将做为回调URL的一个查询参数被发送。

    （3）自定义的Salesforce应用程序将对受权码进行持久化。注意，此受权码不是OAuth2访问令牌。

    （4）一旦存储了受权码，自定义的Salesforce应用程序就能够向Salesforce应用程序出示在注册过程当中生成的密钥，并将受权码返回给EagleEye OAuth2服务器。EagleEye OAuth2服务器将确认受权码是否有效，而后将OAuth2令牌返回给自定义的Salesforce应用程序。每次自定义的Salesforce应用程序须要对用户进行验证并获取OAuth2访问令牌时，都会使用此受权码。

（5）Salesforce应用程序将在HTTP首部中传递OAuth2令牌以调用EagleEye组织服务。

    （6）组织服务将经过EagleEye OAuth2服务来确认传入EagleEye服务调用的OAuth2访问令牌。若是令牌有效，组织服务将处理用户的请求。

    这真的太使人激动了！应用程序到应用程序的集成是错综复杂的。这整个流程中要注意的是，即便用户登陆到Salesforce而且正在访问EagleEye数据，用户的EagleEye凭据也不会直接暴露给Salesforce。在EagleEye OAuth2服务生成并提供初始受权码以后，用户就不再用向EagleEye服务提供他们的凭据了。

    B.4　隐式受权

    受权码模式能够在经过传统的服务器端Web编程环境（如Java或.NET）运行Web应用程序时使用。若是客户端应用程序是纯JavaScript应用程序或彻底在Web浏览器中运行的移动应用程序，而且不依靠服务器端调用来调用第三方服务，那么会发生什么呢？

    这就是最后一种受权类型，即隐式受权，可以发挥做用的地方。图B-4展现了在隐式受权中发生的通常流程。

 

图B-4　隐式受权用于基于浏览器的单页面应用程序（Single-Page Application，SPA） JavaScript应用程序

    

隐式受权一般用于处理彻底在浏览器内运行的纯JavaScript应用程序。在其余受权流程中，客户端与执行用户请求的应用程序服务器（客户端应用程序-已经注册了）进行通讯，而后应用程序服务器与下游服务进行交互。使用隐式受权类型，全部的服务交互都直接从用户的客户端（一般是Web浏览器）发生。在图B-4中，正在进行如下活动：

 

    （1）JavaScript应用程序的全部者已经经过EagleEye OAuth2服务器注册了应用程序。他们提供了一个应用程序名称以及一个回调URL，该URL将被重定向并带有用户的OAuth2访问令牌。

    （2）JavaScript应用程序将调用OAuth2服务。JavaScript应用程序必须出示预注册的应用程序名称。OAuth2服务器将强制用户进行验证。

    （3）若是用户成功进行了验证，那么EagleEye OAuth2服务将不会返回一个令牌，而是将用户重定向回一个页面，该页面是JavaScript应用程序全部者在第一步中注册的页面。在重定向回的URL中，OAuth2访问令牌将被OAuth2验证服务做为查询参数传递。

    （4）应用程序将接收传入的请求并运行JavaScript脚本，该脚本将解析OAuth2访问令牌并将其存储（一般做为Cookie）。

    （5）每次调用受保护资源时，就会将OAuth2访问令牌出示给调用服务。

    （6）调用服务将确认OAuth2令牌，并检查用户是否被受权执行他们正在尝试的活动。

    关于OAuth2隐式受权，记住下面几点。

    隐式受权是惟一一种OAuth2访问令牌直接暴露给公共客户端（Web浏览器）的受权类型。在受权码受权中，客户端应用程序得到一个返回到托管应用程序的应用程序服务器的受权码。经过受权码受权，用户能够经过出示受权码来得到OAuth2访问权限。返回的OAuth2令牌不会直接暴露给用户的浏览器。在客户端凭据受权中，受权发生在两个基于服务器的应用程序之间。在密码受权中，向服务发出请求的应用程序和这个服务都是可信的，而且属于同一个组织。

    由隐式受权生成的 OAuth2 令牌更容易受到攻击和滥用，由于令牌可供浏览器使用。在浏览器中运行的任何恶意JavaScript均可以访问OAuth2访问令牌，并以他人的名义调用他人为了调用服务而检索到的OAuth2令牌，实质上是在模拟他人。

    隐式受权类型的OAuth2令牌应该是短暂的（1～2小时）。由于OAuth2访问令牌存储在浏览器中，因此OAuth2规范（和Spring Cloud Security）不支持能够自动更新令牌的刷新令牌的概念。

 

B.5　如何刷新令牌

    当OAuth2访问令牌被颁发时，其有效时间是有限的，它最终会过时。当令牌到期时，调用应用程序（和用户）将须要使用OAuth2服务从新进行验证。可是，在大多数OAuth2受权流程中，OAuth2服务器将同时颁发访问令牌和刷新令牌。客户端能够将刷新令牌出示给OAuth2验证服务，该服务将确认刷新令牌，而后发出新的OAuth2访问令牌。来看看图B-5，查看一下刷新令牌流程。

 

图B-5　刷新令牌可让应用程序获取新的访问令牌而不强制用户从新进行验证

    （1）用户已经登陆了EagleEye，而且早已经过EagleEye OAuth2服务进行了验证。用户正在愉快地工做，可是，他们的令牌已通过期了。

    （2）用户下一次尝试调用服务（如组织服务）时，EagleEye应用程序将把过时的令牌传递给组织服务。

    （3）组织服务将尝试使用OAuth2服务确认令牌，OAuth2服务返回HTTP状态码401（未经受权）和一个JSON净荷，指示该令牌再也不有效。组织服务将把HTTP状态码401返回给调用服务。

    （4）EagleEye应用程序收到HTTP状态码401和JSON净荷，指出调用从组织服务失败的缘由。EagleEye应用程序将使用刷新令牌调用OAuth2验证服务。OAuth2验证服务将确认刷新令牌，而后发回新的访问令牌。