OAuth2.0 入门与进阶

1、基础知识

一、OAuth产生背景

　　不少网站、APP 弱化甚至没有搭建本身的帐号体系，而是直接使用社会化登陆的方式，这样不只免去了用户注册帐号的麻烦、还能够获取用户的好友关系来加强自身的社交功能。

　　好比咱们可使用微博登陆简书，简书会自动将你的微博头像设置为你的简书头像，将你的微博昵称设置为你的简书昵称，甚至还能够获取你微博中的好友列表，提示你哪些朋友已经在使用简书，这是如何作到的呢？

最传统的办法是让用户直接在简书的登陆页面输微博的帐号和密码，简书经过用户的帐号和密码去微博那里获取用户数据，但这样作有不少严重的缺点：

• 简书须要明文保存用户的微博帐号和密码，这样很不安全。
• 简书拥有了获取用户在微博全部的权限，包括删除好友、给好友发私信、更改密码、注销帐号等危险操做。
• 用户只有修改密码，才能收回赋予简书的权限。可是这样作会使得其余全部得到用户受权的第三方应用程序所有失效。
• 只要有一个第三方应用程序被破解，就会致使用户密码泄漏，以及全部使用微博登陆的网站的数据泄漏。

为了解决以上的问题，OAuth 协议应运而生。

二、定义

　　OAuth2.0（开放受权）是一个关于受权的开放的网络协议。

　　--->容许用户让第三方应用访问该用户在某一网站上存储的的资源（如：照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。

　　--->OAuth是一个关于受权（Authorization）的开放网络标准，目前的版本是2.0版。注意是Authorization(受权)，而不是Authentication(认证)。用来作Authentication(认证)的标准叫openid connect。

三、基本原理

　　OAuth在第三方应用与服务提供商之间设置了一个受权层。第三方应用不能直接登陆服务提供商，只能登陆受权层，以此将用户与客户端区分开来。第三方应用登陆受权层所用的令牌，与用户的密码不一样。用户能够在登陆受权的时候，指定受权层令牌的权限范围和有效期。 
第三方应用登陆受权层之后，服务提供商根据令牌的权限范围和有效期，向第三方应用开放用户资源。

四、做用

　　让客户端安全可控地获取用户的受权，与服务提供商之间进行交互。能够免去用户同步的麻烦，同时也增长了用户信息的安全。

五、经常使用应用场景

• 用OAuth来实现第三方应用对咱们API的访问控制；
• 登陆第三方应用（APP或网页）时，常常会采用其余用户登陆方式，好比QQ，微博，微信的受权登陆（QQ用户登陆）。

六、协议流程

　　（A）用户打开客户端之后，客户端要求用户给予受权。

　　（B）用户赞成给予客户端受权。

　　（C）客户端使用上一步得到的受权，向认证服务器申请令牌。

　　（D）认证服务器对客户端进行认证之后，确认无误，赞成发放令牌。

　　（E）客户端使用令牌，向资源服务器申请获取资源。

　　（F）资源服务器确认令牌无误，赞成向客户端开放资源。

　　不难看出来，上面六个步骤之中，B是关键，即用户怎样才能给于客户端受权。有了这个受权之后，客户端就能够获取令牌，进而凭令牌获取资源。

七、客户端的受权模式

　　----客户端获取受权的四种模式

客户端必须获得用户的受权（authorization grant），才能得到令牌（access token）。OAuth 2.0定义了四种受权方式。

• 受权码模式（authorization code）
• 简化模式（implicit）
• 密码模式（resource owner password credentials）
• 客户端模式（client credentials）

（1）受权码模式（authorization code）

　　功能最完整、流程最严密的受权模式。它的特色就是经过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。

（2）简化模式（implicit grant type）

　　不经过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"受权码"这个步骤，所以得名。全部步骤在浏览器中完成，令牌对访问者是可见的，且客户端不须要认证。

（3）密码模式（Resource Owner Password Credentials Grant）

　　用户向客户端提供本身的用户名和密码。客户端使用这些信息，向"服务商提供商"索要受权。在这种模式中，用户必须把本身的密码给客户端，可是客户端不得储存密码。这一般用在用户对客户端高度信任的状况下，好比客户端是操做系统的一部分，或者由一个著名公司出品。而认证服务器只有在其余受权模式没法执行的状况下，才能考虑使用这种模式。

 

（4）客户端模式（Client Credentials Grant）

　　指客户端以本身的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以本身的名义要求"服务提供商"提供服务，其实不存在受权问题。

 注：web资源：其实就是接口。

 

2、受权码模式

　　---以使用微博帐号登陆简书为示例详细讲解其工做原理

一、原理概要

新浪微博做为服务提供商，拥有用户的头像、昵称、邮箱、好友以及全部的微博内容，简书但愿获取用户存储在微博的头像和昵称，假设它们是三我的：

1. 简书问新浪微博：我想要获取用户 A 的头像和昵称，请你提供
2. 微博说：我须要通过用户Ａ 本人的许可，而后去问用户 A 是否要受权简书访问本身的头像和昵称
3. 用户 A 对微博说：我给简书一个临时的钥匙，若是他给你出示了这把钥匙，你就把个人资料给他
4. 简书使用户给它的钥匙获取用户头像和昵称信息。

以上是 OAuth 认证的大概流程。在使用微博受权以前，简书须要先在微博开放平台上注册应用，填写本身的名称、logo、用途等信息，微博开放平台颁发给简书一个应用 ID 和叫 APP Secret 的密钥，在实际对接中，会使用到这两个参数。

注：

• 新浪微博开放平台便是认证服务器
• 用户发放code（时间极短）
  认证服务器发放 token（时间长）
• 资源服务器提供用户资源

 二、详细流程

接下来分步详细解释上图中每步都作了什么：

　　1.用户点击简书上的微博登陆按钮，跳转到微博受权页面。微博登陆按钮的连接形以下方的 URL：

 https://api.weibo.com/oauth2/authorize?client_id=123050457758183&redirect_uri=http://jianshu.com/callback

　　URL 中要包含如下参数：

• client_id：在微博开放平台申请的应用 ID
• redirect_uri：受权成功后要跳转到的地址

 　　点击以上连接后跳转到微博的受权页面以下图：

　　这个页面会告诉用户第三方应用要获取用户的哪些数据，以及拥有什么权限，好比在上图中简书会要求得到我的信息、好友关系、分享内容到微博以及得到评论的权限，用户点击“容许”则表示容许简书得到这些数据，进行下一步。

　　2.页面自动跳转到初始参数中redirect_uri 定义的那个URL，并自动在 URL 末尾添加一个 code 参数，实际跳转的地址形如:

http://jianshu.com/callback?code=2559200ecd7ea433f067a2cf67d6ce6c

　　3.第三步，简书经过上一步获取的 code 参数换取 Token，Token 就是前文中说到的钥匙。简书请求以下的接口获取 Token：

　　POST https://api.weibo.com/oauth2/access_token
　　要包含如下参数：

• client_id：在微博开放平台申请的应用 ID
• client_secret：在微博开放平台申请时提供的APP Secret
• grant_type：须要填写authorization_code
• code：上一步得到的 code
• redirect_uri：回调地址，须要与注册应用里的回调地址以及第一步的 redirect_uri 参数一致

　注：获取token十分重要，采用POST方式比较安全。

 

　4.经过第三步的请求，接口返回 Token 和相关数据：

{
 "access_token": "ACCESS_TOKEN",//Token 的值
 "expires_in": 1234,//过时时间
 "uid":"12341234"//当前受权用户的UID。
}

　　5.在第四步中获取了access_token ，使用它，就能够去获取用户的资源了，要获取用户昵称和头像，请求以下接口：

　　GET https://api.weibo.com/2/users/show.json

　　携带参数：

• access_token：上一步获取的access_token
• uid：用户的帐号 id，上一步的接口有返回

　　注：access_token使用时间有限，若失效，经常使用的解决方法：

• 从新受权登陆
• 使用refresh_token，从新申请。（通常用在不间断连续在线）

 

　　6.最后一步，微博返回用户信息，简书进行处理，整个流程结束。

　　经过以上的方式，在简书和新浪微博中间创建了一个独立的权限层，这个权限由用户赋予，能够被用户随时取消，不一样第三方应用之间相互独立，互不干扰，这样就完全解决了明文存放帐号密码的问题。

 

 总结：

　　目前不少互联网公司都提供了本身的开放平台使第三方应用接入。开源项目中也有不少框架提供了OAuth的实现，例如Spring Security OAuth，Apache Oltu等。使用OAuth协议可以很好的保证第三方应用访问用户数据的安全性。

 

参考文献：

　　https://www.jianshu.com/p/0db71eb445c8

　　http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html