OAuth2.0介绍

OAuth2.0是OAuth1.0的延续版本,可是不向后兼任,本文只讨论2.0版本.

OAuth是一个开放标准,容许用户让第三方应用访问该用户在某一网站上存储的私密的资源,而无需将用户名和密码提供给第三方应用.

其实这种场景在如今已经十分广泛,好比不少论坛,都会开放支持使用QQ登陆,试想若是没有OAuth,你在碰见这些感兴趣的论坛想进行评论发帖时,要么注册一个论坛帐号,要么把你的QQ帐号密码直接告诉论坛,很显然前者很繁琐,后者不安全,而OAuth正是帮你解决这些问题.

OAuth引入了受权层来区分用户和第三方客户端,不一样于用户直接使用我的密码凭证,客户端使用令牌来访问用户的私密资源,该令牌包含诸如:范围,有效期以及其余的访问相关属性.

OAuth定义了四种角色:

1. resource owner(资源全部者):一个容许访问受保护资源的实体,若是这是一我的,也叫作终端用户.
2. resource server(资源服务器):这台服务器承载着受保护的资源,它有能力接收并响应哪些对受保护资源发起的请求.
3. client(客户端):经过资源全部者和他的受权发起访问受保护资源的应用
4. authorization server(受权服务器):在成功验证资源全部者并得到受权后,发送令牌给客户端

OAuth协议流程:

（A）客户端请求资源全部者受权(受权请求能够直接经过资源全部者,更好的方式是使用受权服务器做为中介).

（B）若资源全部者赞成受权,客户端会接收到受权许可.

（C）客户端使用上一步得到的受权许可,向受权服务器申请令牌.

（D）受权服务器对客户端的受权许可进行验证,确认无误后发放令牌.

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

（F）资源服务器对令牌进行验证,确认无误后赞成向客户端开放资源.

在上述六个步骤中,第二步客户端得到受权许但是关键步骤,OAuth定义了四中受权方式:

Authorization Code(受权码模式):

受权码模式使用受权服务器做为客户端和资源全部者的中介,不直接向资源全部者请求受权,而是经过客户端引导资源全部者到受权服务器(经过用户代理:如浏览器),受权服务器会验证资源全部者,验证经过得到受权后,会从新引导资源全部者返回到客户端页面,此时,客户端就能够获得受权码.由于资源全部者仅在受权服务器进行了身份验证,因此他的凭证不会被客户端所获取.受权码模式提供了很好的安全保障,好比能够验证客户端身份,直接传输令牌到客户端而不须要通过用户代理从而被暴露给其余人的可能性.

(A) 客户端导向资源全部者的用户代理到受权服务器,在此过程当中会同时传递客户端标识,请求范围,本地状态以及一个用于受权服务器回跳的URI.

• response_type:表示受权类型,必选项,此处的值固定为"code"
• client_id:表示客户端的ID,必选项
• redirect_uri:表示重定向URI,可选项
• scope:表示申请的权限范围,可选项
• state:表示客户端的当前状态,能够指定任意值,认证服务器会原封不动地返回这个值.

(B) 受权服务器验证资源全部者并决定是否赞成客户端的受权申请.

(C) 假设资源全部者赞成访问,受权服务器就会重定向用户代理到客户端以前指定的回跳地址,并附上一个受权码.

• code:表示受权码,必选项.该码的有效期应该很短,一般设为10分钟,客户端只能使用该码一次,不然会被受权服务器拒绝.该码与客户端ID和重定向URI,是一一对应关系.
• state:若是客户端的请求中包含这个参数,认证服务器的回应也必须如出一辙包含这个参数.

(D) 客户端附上以前得到的受权码向受权服务器申请令牌,这个请求过程受权服务器将会验证客户端身份.

• grant_type:表示使用的受权模式,必选项,此处的值固定为"authorization_code".
• code:表示上一步得到的受权码,必选项.
• redirect_uri:表示重定向URI,必选项,且必须与A步骤中的该参数值保持一致.
• client_id:表示客户端ID,必选项.

(E) 受权服务器验证客户端身份,确认受权码,并确保收到的回跳地址和在C步骤中得一致.若是全都验证经过,受权服务器返回访问令牌和更新令牌给客户端.

• access_token:表示访问令牌,必选项.
• token_type:表示令牌类型,该值大小写不敏感,必选项,能够是bearer类型或mac类型.
• expires_in:表示过时时间,单位为秒.若是省略该参数,必须其余方式设置过时时间.
• refresh_token:表示更新令牌,用来获取下一次的访问令牌,可选项.
• scope:表示权限范围,若是与客户端申请的范围一致,此项可省略.

Implicit(隐式受权模式):

隐式受权是针对基于浏览器实现的使用脚本语言的客户端的简化版受权码流程,它会直接给客户端分配访问令牌而不是受权码.服务器也不回验证客户端身份而是经过验证回跳URL来验证客户端ID,而后把令牌传递给客户端.隐式受权模式提升了响应能力和效率,由于它减小了得到令牌的请求次数.然而易用性上升的同时也会在安全性上有所降低,咱们须要权衡利弊.

(A) 客户端导向资源全部者的用户代理到受权服务器,在此过程当中会同时传递客户端标识,请求范围,本地状态以及一个用于受权服务器回跳的URI.

• response_type：表示受权类型，此处的值固定为"token"，必选项。
• client_id：表示客户端的ID，必选项。
• redirect_uri：表示重定向的URI，可选项。
• scope：表示权限范围，可选项。
• state：表示客户端的当前状态，能够指定任意值，认证服务器会原封不动地返回这个值。

(B) 受权服务器验证资源全部者并决定是否赞成客户端的受权申请.

(C) 假设资源全部者赞成访问,受权服务器就会重定向用户代理到客户端以前指定的回跳地址,并附上令牌片断.

• access_token：表示访问令牌，必选项。
• token_type：表示令牌类型，该值大小写不敏感，必选项。
• expires_in：表示过时时间，单位为秒。若是省略该参数，必须其余方式设置过时时间。
• scope：表示权限范围，若是与客户端申请的范围一致，此项可省略。
• state：若是客户端的请求中包含这个参数，认证服务器的回应也必须如出一辙包含这个参数。

(D) 用户代理请求客户端页面资源(并本地维持片断信息).

(E) 返回一个包含脚本的页面,它能够提取片断中的令牌信息.

(F) 用户代理执行本地脚本进而提取令牌.

(G) 用户代理传递令牌给客户端.

Resource Owner Password Credentials(密码模式):

密码模式适用于资源全部者信任高度信任客户端的场景,例如设备操做系统或者一些特权应用.受权服务器应该只有再没法执行其余模式的状况下才采用该种模式.

(A) 资源全部者提供本身的用户名和密码给客户端.

(B) 客户端使用得到的凭证向受权服务器申请令牌.

(C) 受权服务器验证客户端凭证,若是经过,返回令牌.

• access_token：表示访问令牌，必选项。
• token_type：表示令牌类型，该值大小写不敏感，必选项，能够是bearer类型或mac类型。
• expires_in：表示过时时间，单位为秒。若是省略该参数，必须其余方式设置过时时间。
• refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
• scope：表示权限范围，若是与客户端申请的范围一致，此项可省略。

Client Credentials(客户端模式):

客户端以本身的名义,而不是以资源全部者的名义,向受权服务器进行认证.在这种模式中,用户直接向客户端注册,客户端以本身的名义要求受权服务器提供服务,其实不存在受权问题.

(A) 客户端向受权服务器申请令牌.

(B) 资源服务器验证客户端,经过后返回令牌.

更新令牌:

当访问令牌失效过时时,咱们须要使用更新令牌来从新得到访问令牌.不一样于访问令牌,更新令牌永远都不会被用于资源服务器.

(A) 客户端向受权服务器请求令牌.

(B) 受权服务器验证客户端身份并验证受权许可,若是经过,返回访问令牌和更新令牌.

(C) 客户端使用访问令牌向资源服务器申请受保护资源.

(D) 资源服务器验证访问令牌,若是有效,提供资源服务.

(E) 重复C,D步骤直至访问令牌失效.

(F) 由于访问令牌失效,资源服务器返回令牌失效错误.

(G) 客户端使用更新令牌向受权服务器申请新的访问令牌.

(H) 受权服务器验证客户端身份和更新令牌,若是经过,返回一个新的访问令牌.

 

参考资料地址:

https://tools.ietf.org/html/rfc6749

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

https://www.cnblogs.com/flashsun/p/7424071.html