OAuth2.0 协议摘要理解，附亚马逊 AVS 服务认证流程图

这个文章主要用来给自己对OAuth2.0提个醒，之前在工作中一直用到的是Authorization Code模式，对整体的流程有一定的理解，但是看网上的文章发现有的看不明白，原来是对这个协议的细节不是很了解，所以记录下协议中定义的几个角色以及这些角色在实际开发中对应的实体，能很好的帮助理解业务流程。

下面的图是我根据协议的理解，对照亚马逊 Alex Voice Service （AVS）客户端写画的认证流程。

AVS认证流程，框内对比的给出每个实体对应协议中的角色定义

 

作用

OAuth 2.0授权框架允许第三方应用程序通过如下任意一种方式获取有限制的访问：

1. 第三方应用代表资源拥有者发起在资源拥有者和HTTP服务之间的互动。
2. 第三方应用通过其身份来获取访问权限。

协议中角色定义

• 资源所有者（resource owner）： 能够对受保护资源授予访问权限的实体。当资源所有者是一个人时，它被称为终端用户。

• 资源服务器（resource server）： 托管受保护资源的服务器，能够接受和响应通过令牌对受保护的资源的请求。

• 客户端（client）： 代表资源所有者及其授权进行受保护资源请求的应用程序。术语“客户端”并不暗示任何特定的实现特征（例如，应用程序是在服务器，台式机还是其他设备上执行）。

• 授权服务器（authorization server）： 成功后，服务器向客户端发出访问令牌验证资源所有者并获得授权。

Authorization Grant

（A）客户端请求资源所有者授权。该授权请求可以直接直接呈现给资源拥有者，也可间接地通过授权服务器进行（例如跳转到授权服务器）。

（B）客户端收到授权许可，即表示资源所有者授权的凭证，使用本规范中定义的四种授权类型之一或使用扩展授权类型表示。授权许可类型取决于客户端使用何种方法请求授权服务器，以及授权服务器支持哪些授权类型。

（C）客户端通过向授权服务器进行认证并呈现用户赋予的权限来请求access token。

（D）授权服务器验证客户端并验证用户赋予的权限，如果有效，则颁发access token。

（E）客户端从资源服务器请求受保护资源，并通过呈现access token进行身份验证。

（F）资源服务器验证access token，如果有效，则为该请求提供服务。

客户端从资源所有者获得授权授权的首选方法（如步骤（A）和（B）所示）是使用授权服务器作为中介

• Protocol Flow

       +--------+                               +---------------+
       |        |--(A)- Authorization Request ->|   Resource    |
       |        |                               |     Owner     |
       |        |<-(B)-- Authorization Grant -