OAuth 流程与发展总结 (1.0 => 1.0a => 2.0)

摘要：如果不使用回调地址桌面或手机程序，而是通过手动拷贝粘贴完成授权的话，那么只要攻击者在在前面发起请求，就能拿到的。改进步骤传递参数而不是获取已授权步骤申请时，必须传递让参与签名避免攻击者假冒。

概述: 开放授权协议

作用: 允许第三方应用访问服务提供方中注册的终端用户的部分资源
下面是官方描述: [OAuth描述] The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

参与者:

Client (Consumer) => 第三方应用

Resource Owner(User) => 用户

Resource Server(Service Provider) => 资源服务提供方(OAuth2.0将服务提供方拆分为两部分)

Authorization Server(Service Provider) => 授权服务提供方(OAuth2.0将服务提供方拆分为两部分)

OpenID (WHO) 和 OAuth (WHAT)
=> OpenID 更加关注 "我是谁" 的问题
=> OAuth 更加关注 "我能获得哪些权限的问题"

(步骤 A) Consumer申请Request Token（/oauth/1.0/request_token）：
oauth_consumer_key
oauth_signature_method
oauth_signature
oauth_timestamp
oauth_nonce
oauth_version

(步骤 B) Service Provider返回Request Token：
oauth_token
oauth_token_secret

(步骤 C) Consumer重定向User到Service Provider（/oauth/1.0/authorize）：
oauth_token
oauth_callback

(步骤 D) Service Provider在用户授权后重定向User到Consumer：
oauth_token

(步骤 E) Consumer申请Access Token（/oauth/1.0/access_token）：
oauth_consumer_key
oauth_token
oauth_signature_method
oauth_signature
oauth_timestamp
oauth_nonceoauth_version

(步骤 F) Service Provider返回Access Token：
oauth_token
oauth_token_secret

如果Service Provider没有限制回调地址（应用设置没有限定根域名一致），那么攻击者可以把oauth_callback设置成成自己的URL。

如果Consumer不使用回调地址（桌面或手机程序），而是通过User手动拷贝粘贴Request Token完成授权的话，那么只要攻击者在在User前面发起请求，就能拿到User的Access Token。

步骤 B 传递 callback_url参数 (而不是 获取已授权 request_token 步骤) Consumer申请Request Token时，必须传递oauth_callback, 让callback参与签名, 避免攻击者假冒callback。

验证完未授权 request_token 返回新的参数 oauth_verifier 验证完成后会返回验证码(oauth_verifier)在没有callback的时候, 服务提供方显示给用户，然后用户可以在第三方应用的设备上输入，标示自己已经授权（和未授权的用户分开），然后第三方应用必须加上该验证码去获取

OAuth 2.0定义了四种授权方式。

授权码模式（authorization code）(本文只讲解该授权方式)

简化模式（implicit）

密码模式（resource owner password credentials）

客户端模式（client credentials）

(步骤 A) Client 向Authorization Server发出申请（/oauth/2.0/authorize）：
response_type = code
client_id
redirect_uri
scope
state

(步骤 B) Authorization Server 在Resource Owner授权后给Client返回
code
state

(步骤 C) Client向Authorization Server发出申请（/oauth/2.0/token）：
grant_type = authorization_code
code
client_id
client_secrect
redirect_uri

(步骤 E) Server在Resource Owner授权后给Client返回Access Token：
access_token
token_type
expires_in
refresh_token

[RFC 对state参数的解释]
The authorization server SHOULD require the client to provide the complete redirection URI (the client MAY use the "state" request parameter to achieve per-request customization). If requiring the registration of the complete redirection URI is not possible, the authorization server SHOULD require the registration of the URIscheme, authority, and path (allowing the client to dynamically vary only the query component of the redirection URI when requesting authorization).
我们假设出现下面的场景:
（1）用户甲到第三方网站A登录后，到了绑定页面。此时还没绑定微博。
（2）绑定页面提供一个按钮：“绑定微博”（地址a：http://aaa.com/index.php?m=us...）
（3）用户甲点击地址a，程序生成如下地址b：
https://api.weibo.com/oauth2/...【9999999】&redirect_uri=【http://aaa.comindex.php】&response_type=【code】
（4）用户甲浏览器定向到地址b，授权该应用。
（5）授权服务器根据传递的redirect_uri参数，组合认证参数code生成地址c：
http://aaa.comindex.php&code=【809ui0asduve】
（6）用户甲浏览器返回到地址c,完成绑定
此时即使我们交换两个用户的地址c,则会出现绑定错误的情况,避免出现该情况的办法就是对state参数进行验证,来判断该state参数是否是该用户所对应的重定向地址

https://huoding.com/2010/10/10/8 《OAuth那些事儿》

https://huoding.com/2011/11/0... 《OAuth的改变》

https://www.zhihu.com/questio...《Oauth 1.0 1.0a 和 2.0 的之间的区别有哪些？》

http://www.ruanyifeng.com/blo... 《理解 OAuth2.0》

http://blog.sina.com.cn/s/blo... 《小议OAuth 2.0的state参数——从开发角度也说《互联网最大规模帐号劫持漏洞即将引爆》》

https://tools.ietf.org/html/r... 《RFC 6749》

这篇文章是参考网上的资料的总结, 如果有错误欢迎批评指正, 如果侵权, 请作者联系我删除文章, 谢谢
有兴趣的同学也可以参照 [微博OAuth] API, 申请一个第三方应用, 参照微博API去实现一个获取 access_token的测试用例 (微博会给予申请的第三方应用 client_id, client_secret)