一、简介
不使用oauth2.0协议，资源所有者直接给需要使用资源的第三方应用共享凭据时，有这些问题：
- 需要直接共享给第三方应用凭据
- 需要服务器支持密码身份验证
- 凭据的访问权限过大，失去对访问时间和范围的控制
- 不能灵活撤销发出的凭据
- 任何第三方都要共享凭据
oauth引入了授权层，分离了客户端和资源所有者的角色
客户端在请求资源时，被颁发的是另一套凭据
1、角色
oauth的四种角色：
- 资源所有者
- 资源服务器
- 客户端
- 授权服务器
授权服务器和资源服务器可以是同一台，授权服务器可以颁发被多个资源服务器接受的访问令牌
2、协议流程
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
客户端用于从资源所有者获得授权许可（步骤（A）和（B）所示）的更好方法是使用授权服务器作为中介，而不是直接从资源所有者获取
3、授权许可
（一）授权码
客户端引导资源所有者至授权服务器，许可后授权服务器引导资源所有者带着code授权码回到客户端，客户端再带着code访问授权服务器获取token
（二）隐式许可
简化的授权码模式，资源所有者在授权服务器验证通过以后，直接带着token令牌返回客户端。
减少请求往返的数量，增加了安全风险。在传输的过程中暴露了令牌，没有对客户端做验证
（三）资源所有者密码凭据
当资源所有者和客户端高度信任时，客户端直接带着资源所有者的密码凭据访问授权服务器，换回token
用来一次性获取令牌，客户端可以不用保存资源所有者的密码凭据
（四）客户端凭据
当客户端自己代表资源所有者或者实现和授权服务器约定好时，客户端带着自己的凭据访问授权服务器，换回token
4、访问令牌
令牌代表了访问权限的由资源所有者许可并由资源服务器和授权服务器实施的具体范围和期限
5、刷新令牌
授权服务器可以在颁发访问令牌时多颁发一个刷新令牌
- 用于客户端在访问令牌即将过期时向授权服务器换取新访问令牌
- 用于客户端向授权服务器换取权限相等或更窄范围的访问令牌
+--------+ +---------------+ | |--(A)------- Authorization Grant --------->| | | | | | | |<-(B)----------- Access Token -------------| | | | & Refresh Token | | | | | | | | +----------+ | | | |--(C)---- Access Token ---->| | | | | | | | | | | |<-(D)- Protected Resource --| Resource | | Authorization | | Client | | Server | | Server | | |--(E)---- Access Token ---->| | | | | | | | | | | |<-(F)- Invalid Token Error -| | | | | | +----------+ | | | | | | | |--(G)----------- Refresh Token ----------->| | | | | | | |<-(H)----------- Access Token -------------| | +--------+ & Optional Refresh Token +---------------+
二、客户端注册
客户端需要在授权服务器上注册，不用直接交互，可以依靠其他方式来建立信任关系
当注册客户端时，客户端开发者应该：
- 指定客户端类型
- 提供客户端重定向URI
- 包含授权服务器要求的任何其他信息（如，应用名称、网址、描述、Logo图片、接受法律条款等）
1、客户端类型
根据安全情况分：
- 机密客户端
- 公开客户端
根据客户端配置分：
- Web应用程序
- 基于用户代理的应用
- 本机应用程序
2、客户端标志
一个代表客户端提供的注册信息的唯一字符串
3、客户端身份验证
使用client_id和client_secret作为客户端凭据
使用Basic Authorization基本认证在请求正文中传输，例如：
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
三、协议端点
授权过程采用了两种授权服务器端点（HTTP资源）：
- 授权端点——客户端用其通过用户代理重定向从资源所有者获取授权。
- 令牌端点——客户端用其将授权许可交换为访问令牌，通常伴有客户端身份验证。
以及一种客户端端点：
- 重定向端点——授权服务器用其通过资源所有者用户代理向客户端返回含有授权凭据的响应。
并不是每种授权许可类型都采用两种端点。
1、授权端点
授权端点被授权码许可类型和隐式许可类型流程使用
客户端使用response_type参数通知授权服务器期望的许可类型，"code"是授权码许可，"token"是隐式许可
完成资源所有者的交互后，授权服务器将用户代理重定向至重定向端点"redirect_uri"
授权服务器必须要求公开客户端和采用隐式许可的机密客户端注册重定向端点，必须是绝对URI，可以注册多个
2、令牌端点
客户端使用授权许可或刷新令牌从令牌端点获取令牌，只有隐式许可用不到
当发起令牌请求时必须使用"POST"方法
在向令牌端点发起请求时，机密客户端或其他被颁发客户端凭据的客户端与授权服务器进行身份验证，可以使用“client_id”请求参数标识自己
3、访问令牌范围
客户端可以使用“scope”参数来指定访问请求的范围