1. OAuth2.0深入理解
1.1. 概念
- OAuth（Open Authorization）开放授权，表示将系统功能部分授权给第三方系统调用，实现更细颗粒度的权限控制
- OAuth是一种在线授权或者现场授权；IAM服务是一种预先授权或者离线授权
- 通俗的将，OAuth协议的用途，比如我要用在线打印服务来打印网盘里的照片，一般做法有两种，一是从网盘下下来，上传到在线打印服务；二是把网盘账号密码告诉在线打印服务，由在线打印服务去做下载上传的操作。这两种做法一是太麻烦，二是不安全，OAuth就是为了这种情况设计的，将网盘的下载权限授权给在线打印，就可以完成此操作
1.2. 组成
1.2.1. 协议参与者
- OAuth的参与实体至少有如下三个：
- RO (resource owner): 资源所有者，对资源具有授权能力的人。如上文中的用户Alice。
- RS (resource server): 资源服务器，它存储资源，并处理对资源的访问请求。如Google资源服务器，它所保管的资源就是用户Alice的照片。
- Client: 第三方应用，它获得RO的授权后便可以去访问RO的资源。如网易印像服务。
- 为了支持开放授权功能以及更好地描述开放授权协议，OAuth引入了第四个参与实体：
- AS (authorization server): 授权服务器，它认证RO的身份，为RO提供授权审批流程，并最终颁发授权令牌(Access Token)。读者请注意，为了便于协议的描述，这里只是在逻辑上把AS与RS区分开来；在物理上，AS与RS的功能可以由同一个服务器来提供服务。
1.2.2. 授权类型
- OAuth为了支持这些不同类型的第三方应用，提出了多种授权类型，如授权码 (Authorization Code Grant)、隐式授权 (Implicit Grant)、RO凭证授权 (Resource Owner Password Credentials Grant)、Client凭证授权 (Client Credentials Grant)。其中最核心、最难理解、也是最广泛使用的一种授权类型——“授权码”
1.2.3. 基本思路
协议的基本流程如下：
(1) Client请求RO的授权，请求中一般包含：要访问的资源路径，操作类型，Client的身份等信息。
(2) RO批准授权，并将“授权证据”发送给Client。至于RO如何批准，这个是协议之外的事情。典型的做法是，AS提供授权审批界面，让RO显式批准。这个可以参考下一节实例化分析中的描述。
(3) Client向AS请求“访问令牌(Access Token)”。此时，Client需向AS提供RO的“授权证据”，以及Client自己身份的凭证。
(4) AS验证通过后，向Client返回“访问令牌”。访问令牌也有多种类型，若为bearer类型，那么谁持有访问令牌，谁就能访问资源。
(5) Client携带“访问令牌”访问RS上的资源。在令牌的有效期内，Client可以多次携带令牌去访问资源。
(6) RS验证令牌的有效性，比如是否伪造、是否越权、是否过期，验证通过后，才能提供服务。
1.2.4. 授权码类型的开放授权
授权码类型的开放授权协议流程描述如下：
(1) Client初始化协议的执行流程。首先通过HTTP 302来重定向RO用户代理到AS。Client在redirect_uri中应包含如下参数：client_id, scope (描述被访问的资源), redirect_uri (即Client的URI), state (用于抵制CSRF攻击). 此外，请求中还可以包含access_type和approval_prompt参数。当approval_prompt=force时，AS将提供交互页面，要求RO必须显式地批准（或拒绝）Client的此次请求。如果没有approval_prompt参数，则默认为RO批准此次请求。当access_type=offline时，AS将在颁发access_token时，同时还会颁发一个refresh_token。因为access_token的有效期较短（如3600秒），为了优化协议执行流程，offline方式将允许Client直接持refresh_token来换取一个新的access_token。
(2) AS认证RO身份，并提供页面供RO决定是否批准或拒绝Client的此次请求（当approval_prompt=force时）。
(3) 若请求被批准，AS使用步骤(1)中Client提供的redirect_uri重定向RO用户代理到Client。redirect_uri须包含authorization_code，以及步骤1中Client提供的state。若请求被拒绝，AS将通过redirect_uri返回相应的错误信息。
(4) Client拿authorization_code去访问AS以交换所需的access_token。Client请求信息中应包含用于认证Client身份所需的认证数据，以及上一步请求authorization_code时所用的redirect_uri。
(5) AS在收到authorization_code时需要验证Client的身份，并验证收到的redirect_uri与第3步请求authorization_code时所使用的redirect_uri相匹配。如果验证通过，AS将返回access_token，以及refresh_token（若access_type=offline）。
1.3. 误解
1.4. 授权服务器
1.5. Spring Security OAuth2
1.6. 扩展
- spring social 对接新浪，微信，qq