OAuth2.0协议详解
OAuth2.0协议详解
⼀、什么是OAuth2.0
OAuth（开放授权）是⼀个开放标准，允许⽤户授权第三⽅移动应⽤访问他们存储在另外的服务提供者上的信息，⽽不需要将⽤户名和密码提供给第三⽅移动应⽤或分享他们数据的所有内容，OAuth2.0是OAuth协议的延续版本，但不兼容OAuth 1.0(即完全废⽌了
OAuth1.0)。
OAuth 2.0 规范定义了⼀个授权（delegation）协议。
⼆、应⽤场景
第三⽅应⽤授权登录：在APP或者⽹页接⼊⼀些第三⽅应⽤时，时长会需要⽤户登录另⼀个合作平台，⽐如QQ(或是微博，)的授权登录。
三、OAuth2.0的四个重要⾓⾊
在OAuth2.0的完整授权流程中有4个重要的⾓⾊参与进来：
Resource Owner： 资源拥有者，上述例⼦中的⽤户。
Resource Server： 资源服务器，上述例⼦中的QQ(或是微博，)。
Client： 客户端，上述例⼦中的第三⽅应⽤，代指任何可以消费资源服务器的第三⽅应⽤；
Authorization Server ： 授权服务器，管理Resource Owner，Client和Resource Server的三⾓关系的中间层。
其中Authorization server和Resource server可以是独⽴的服务提供商，也可以是在⼀起的，⽐如腾讯提供QQ作为资源服务器的同时也提供授权服务。
OAuth2.0解决问题的关键在于使⽤Authorization server提供⼀个访问凭据给Client，使得Client可以在不知道Resource owner在Resource server上的⽤户名和密码的情况下消费Resource owner的受保护资源。qq用户名
四、OAuth2.0的授权流程
在上述的OAuth完整流程中，
（A）->（B）->（C）->（D）是授权的过程（参与者有⽤户，第三⽅应⽤，QQ(或是微博，)，Authorization server）；
（E）->（F）是消费资源的过程（参与者有第三⽅应⽤和QQ(或是微博，)）。
（A）⽤户打开Client(第三⽅应⽤)以后，Client(第三⽅应⽤)向QQ(或是微博，)发起授权请求。
（B）⽤户同意给予Client(第三⽅应⽤)授权，并返回授权许可给Client(第三⽅应⽤)。
（C）Client(第三⽅应⽤)使⽤上⼀步获得的授权，向Authorization server(认证服务器)申请令牌。
（D）Authorization server(认证服务器)验证第三⽅应⽤的⾝份和授权许可，确认⽆误，同意发放Access Token(访问令牌)给Client(第三⽅应⽤)。
（E）Client(第三⽅应⽤)使⽤Access Token(访问令牌)，向Resource Server(资源服务器)申请获取资源。
（F）Resource Server(资源服务器)确认令牌⽆误，同意向Client(第三⽅应⽤)开放资源。
这其中⽐较重要的⼀个概念是Access Token(访问令牌)，它代表的信息是整个OAuth2.0的核⼼，也是ABCD这些步骤最终要得到的信息。
访问令牌是对第三⽅应⽤可以在QQ访问某个⽤户(假设为User_A)的部分信息这个完整权限的⼀个抽象，⽐如第三⽅应⽤要访问User_B在QQ的信息，那么就是另外⼀个访问令牌了。
访问令牌背后抽象的信息有哪些呢?
①第三⽅应⽤标识（⽐如Client_A）；
②⽤户标识（⽐如User_A）；
③客户端能访问资源所有者的哪些资源以及其相应的权限。
有了这三类信息，那么资源服务器（Resouce Server）就可以区分出来是哪个第三⽅应⽤（Client）要访问哪个⽤户（Resource Owner）的哪些资源（以及有没有权限）。
五、四种授权模式
注：以下4种授权模式是对上述(四、OAuth2.0的授权流程)中的ABDE四个阶段的展开。
①授权码模式（authorization code）
②简化模式（implicit）
③密码模式（resource owner password credentials）
④客户端模式（client credentials）
5.1）授权码模式Authorization code
授权码模式（authorization code）是功能最完整、流程最严密的授权模式。
（A）Client使⽤浏览器（⽤户代理）访问Authorization server。也就是⽤浏览器访问⼀个URL，这个URL是Authorization server提供的，访问的Client需要提供（客户端标识，请求范围，本地状态和重定向URL）这些参数。
（B）Authorization server验证Client在（A）中传递的参数信息，如果⽆误则提供⼀个页⾯供Resource owner登陆，登陆成功后选择Client可以访问Resource server的哪些资源以及读写权限。
（C）在（B）⽆误后返回⼀个授权码（Authorization Code）给Client。
（D）Client拿着（C）中获得的授权码（Authorization Code）和参数信息（客户端标识、重定向URL等信息）作为参数，请求Authorization server提供的获取访问令牌的URL。
（E）Authorization server返回访问令牌(Access Token)和可选的刷新令牌(Refresh Token)以及令牌有效时间等信息给Client。
5.1.1）备注说明：
Authorization Request - 请求获取授权码：
对应步骤（A），客户端提供以下参数请求Authorization Server：
response_type：必选。值固定为“code”。
client_id：必选。第三⽅应⽤的标识ID。
redirect_uri：必选。授权成功后的重定向地址。
state：推荐。Client提供的⼀个字符串，服务器会原样返回给Client。
scope：可选。表⽰授权范围。
⽰例：
GET
/authorizeresponse_type=code&client_id=1&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2 Foauth2&scope=user
HTTP/1.1
Host: ample
Authorization Response - 认证服务器返回授权码：
对应步骤（C），Authorization Server会返回如下信息：
code：授权码。
state：步骤（A）中客户端提供的state参数原样返回。
⽰例：
Location头部信息指向步骤（A）提供的redirect_uri地址，同时携带code信息和state信息给client，这样浏览器在重定向的时候就会以GET的⽅式访问Client提供的redirect_uri，同时Client接收到code信息和state信息。
Access Token Request - 请求获取访问令牌(access token)：
对应步骤（D），客户端提供以下参数请求Authorization Server：
grant_type：必选。固定值“authorization_code”。
code : 授权码，必选。Authorization Response 中响应的code。
redirect_uri：重定向URL，必选。必须和Authorization Request中提供的redirect_uri相同。
client_id：必选。必须和Authorization Request中提供的client_id相同。
⽰例：
POST /token HTTP/1.1
Host: ample
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=123&client_id=1&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2 Foauth2
Access Token Response - 认证服务器返回访问令牌(access token)：
对应步骤（E），Authorization Server会返回如下典型的信息：
access_token：访问令牌。
refresh_token：刷新令牌。
expires_in：过期时间。
⽰例：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
“access_token”:“2YotnFZFEjr1zCsicMWpAA”,
“token_type”:“example”,
“expires_in”:3600,
“refresh_token”:“tGzv3JOkF0XG5Qx2TlKWIA”,
“example_parameter”:“example_value”
}
之后就能⽤access_token去获取⽤户数据了。
5.2）简化模式Implicit
这个是Authorization Code的简化版本。其中省略掉了颁发授权码（Authorization Code）给客户端的过程，⽽是直接返回访问令牌和可选的刷新令牌，就安全系数⽽⾔更低。
其适⽤于没有Server服务器来接受处理Authorization Code的第三⽅应⽤，其流程如下：
Authorization Request - 请求获取访问令牌：
客户端提供以下参数请求Authorization Server：
response_type：必选。值固定为“token”。
client_id：必选。第三⽅应⽤的标识ID。
state：推荐。Client提供的⼀个字符串，服务器会原样返回给Client。
redirect_uri：可选。授权成功后的重定向地址。
scope：可选。表⽰授权范围。
重点区别在于response_type为“token”，⽽不再是“code”，redirect_uri也变为了可选参数。
⽰例：
GET
/authorizeresponse_type=token&client_id=1&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2 Foauth2&scope=user
HTTP/1.1
Host: ample

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。