Oauth2.0 授权认证

 

 

 

                                        Oauth2.0 授权认证

 

目录

1. OAuth协议是什么?. 1

2. 应用场景... 1

3. 名词定义... 2

4. 主要流程... 2

5. 四种授权模式... 3

6. 授权码授权方式... 4

  6.1什么是授权码模式?. 4

  6.2步骤详情及接口参数... 6

 

 

 

 

1. OAuth协议是什么?

   OAuth是一个关于授权(Authorization)的开发网络标准,主要应用在第三方登录场景.与以往授权方式不同是OAuth是在服务端进行授权,像CAS是客户端进行授权,且授权不会使第三方触及到用户的账号信息(例如用户名和密码),即第三方无需使用用户的用户名和密码就可以申请获得该用户资源的授权,因此OAuth是安全的.

OAuth是Open Authorization的简写.

 

参考:

1. RFC 6749
2. 阮一峰老师网络日志<理解OAuth2.0>

 

2.应用场景

任何身份认证,本质上是基于对请求方的不信任产生的,所以,身份认证就是解决身份的可信任问题.

 

举个栗子:

当你想用注册新浪微博的时候,注册又嫌麻烦,然后它允许你使用QQ授权登录.

 

 

如果你用QQ登录,你就必须让新浪读取存储在QQ上的头像,昵称等信息.

问题是只有得到用户授权,QQ才会同意新浪读取这些信息,那么新浪应该怎么获取用户授权呢?

 

传统的授权方法:

 

 

 

3.名词解释

   在了解OAuth2.0之前需要了解几个专有名词,方便后续的熟悉oauth:

1. Third-party application: 第三方应用程序,也称客户端(client),即上面的客户端.
2. Resource Owner: 资源拥有者,本文也称用户(user)
3. User agent: 用户代理,即浏览器或App等.
4. Authorization server:认证服务器,即服务提供商专门用来处理认证的服务器.
5. Resource server: 资源服务器,即服务商提供存放用户生成的资源的服务器,它与认证服务器, 可以是同一台服务器,也可以是不同服务器.

 

4.主要流程

OAuth2.0运行流程如下,摘自RFC 6749.

 

主要流程一共涉及四个角色: 客户端,用户,认证服务器和资源服务器; 共六步分别如下:

（A）授权请求。用户打开客户端终端（web or APP）以后，客户端要求用户给予授权。这个授权请求可以直接提交给资源所有者。（如图所示），或最好是间接通过授权层作为中介进行授权。

（B）用户授权。客户端收到了一个来自用户的授权凭证。这个凭证，可以通过四种方式来获取，至于哪四种，下面有介绍。

（C）请求认证服务器授权。客户端使用上面用户授权得到的凭证向认证服务器请求一个拥有特定访问权限的访问令牌（access token），注意，access token 是和权限绑定的。

（D）发放令牌。认证服务器向客户端发放客户端在上一步请求的令牌。

（E）请求资源。客户端使用访问令牌向资源服务器请求用户的受保护的资源。

（F）返回资源。资源服务器验证访问令牌是否有效，确认有效则返回请求的资源。如何判断是否有效呢，当然是调用认证服务器的准备好的服务了。

 

 

5. 四种授权模式

客户端(webor App)必须得到用户的授权(authorization grant)后,才能获得令牌(access token),OAuth2.0有四种授权模式:

• 授权码模式(Authorization code)

• 简化模式(implicit)

• 密码模式(resource owner password credentials)

• 客户端模式(client credentials)

 

 

6.授权码模式详解

6.1什么是授权码模式?

授权码模式特点是通过客户端后台服务器,与”服务提供商”的认证服务器进行互动,授权码方式用于同时获取access token和refresh token,并对信任的客户端进行了优化.由于这是一个重定向的流程,client必须能与resource owner的user-agent(通常是浏览器)进行交互且能够接收到authorization server通过重定向传入的请求.

 

下面是引用RFC 6749官网:

 

 

对上面流程的解析:

（A）客户端将用户浏览器引导向认证端。客户端包含了客户端标识 client_id，请求授权范围 scope，本地状态state，回调地址 redirect_uri，一旦被授权（或被拒绝），认证服务器将会把回调地址返回给浏览器。

（B）用户操作授权，比如用户进行选择资源范围，输入密码点确定发送请求，决定是否给客户端授权。

（C）认证服务器校验用户真实性，假设用户给予授权，认证服务器将用户导向客户端事先指定的回调地址 redirect_uri，回调地址后面同时附上一个授权码code 和之前设置的 state （这里的state，其实就是客户端预留的，用于当授权成功后，执行某些事件等，比如可以放一个js的方法名）。

（D）客户端使用上一步返回的授权码 code 附上之前用来获取授权码的回调地址 redirect_uri 向认证服务器请求一个访问令牌 （access token）。这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E）认证服务器核对了授权码和重定向URI，和在（C）步骤中的两个参数比对确认无误后，向客户端发送访问令牌（access token）和可选的刷新令牌（refresh token）。

 

下面来一个原型图和时序图方便更好的理解:

 

 

 

 

 

6.2步骤详情及接口参数

步骤1: 客户端申请认证的URI

包含以下参数:

response_type: 必须,授权类型. (如授权码模式为authorization code)

client_id:必须,客户端ID.(如QQ登录授权,此ID为APPID)

redirect_uri: 可选,重定向urI.

scope: 可选,表示申请权限的范围.

state: 表示客户端的当前状态,可以指定任意值,认证服务器会原封不动返回这个值.

 

示例:

http://10.231.111.208:8080/leadToLogin?response_type=code&client_id=client&state=xiaomi&redirect_uri=http://10.231.111.208:8081/index

对比其他应用通过QQ登录,请求code:

https://graph.qq.com/oauth2.0/show?which=Login&display=pc&client_id=101019034&response_type=code&scope=get_info%2Cget_user_info&redirect_uri=https%3A%2F%2Fpassport.weibo.com%2Fothersitebind%2Fbind%3Fsite%3Dqq%26state%3DCODE-tc-1HVZ4j-22WtNd-qnXUO5Rhlup4BM1a10cca%26bentry%3Dminiblog%26wl%3D&display=

 

步骤2:认证服务器回应客户端的URI

包含以下参数:

code: 必须,授权码.该授权码可以设置失效时间,客户端只能使用该码一次,否则会被授权服务器拒绝.该码与客户端ID和重定向的URI是一一对应关系.

state: 如果客户端的请求中包含这个参数,认证服务器的回应也必须一模一样包含这个参数.

 

示例:

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xiaomi

 

步骤3:客户端向认证服务器申请令牌的http请求

包含以下参数:

grant_type: 必选项,标识使用授权模式.此处为"authorization code".

code: 必选项,表示上一步获取的授权码.

redirect_uri: 必选项,表示重定向URI,且必须与步骤1参数保持一致.

client_id: 必选项, 表示客户端ID.

示例:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

 

对比其他应用通过微信登录,通过code获取access_token:

https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code

 

步骤4,认证服务器发送HTTP回复

包含以下参数:

access_token:  必选项,表示访问令牌.

refresh_token: 可选项,表示更新令牌,用来获取下一次的访问令牌.

token_type: 必选项,表示令牌类型,不分大小写,可以是bearer类型或mac类型.

expires_in: 表示过期时间,单位为秒. 如果省去该参数,必须在其他地方设置过期时间.

scope: 可选,表示授权范围,如果与客户端申请访问一致 ,此项可省去.

 

示例:

HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache
     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"bearer",
       "expires_in":6666,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

 

对比其他应用通过微信登录,返回样例:

{ 
"access_token":"ACCESS_TOKEN", 
"expires_in":7200, 
"refresh_token":"REFRESH_TOKEN",
"openid":"OPENID", 
"scope":"SCOPE",
"unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"

接口5: 更新令牌

       如果客户端的访问令牌access_token已经过期,则需要使用更新令牌refresh_token,申请一个新的访问令牌.

客户端发出更新令牌的http请求,包含以下参数:

grant_type:  必选项,表示使用授权模式, 此处固定值:”refresh_token”.

Refresh_token: 必选项,表示之前收到的更新令牌.

Scope: 表示申请授权范围,不可以超出上一次申请的范围,如果省去该范围,则表示和上次一致.

 

示例:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA