OAuth流程及发展(1.0=>1.0a=>2.0)Overview概述：开放授权协议作用：允许第三方应用访问注册在serviceproviders下面是官方对终端用户部分资源的描述：[OAuthdescription]OAuth2.0授权框架使第三方应用程序能够获得对HTTP服务的有限访问权限，或者代表资源所有者通过编排批准资源所有者和HTTP服务之间的交互，或者允许第三方应用程序代表自己获取访问权限。参与者：客户端（Consumer）=>第三方应用资源拥有者（用户）=>用户资源服务器（服务提供者）=>资源服务提供者（OAuth2.0将服务提供者拆分为两部分）授权服务器（服务提供者）=>授权服务提供者（OAuth2.0将服务提供者拆分为两部分）OpenID（WHO）和OAuth（WHAT）=>OpenID更关注'whoamI'的问题=>OAuth更关注'whoamI'的问题'我可以获得什么权限'OAuth1.0流程图接口（步骤A）Consumer申请RequestToken（/oauth/1.0/request_token）：oauth_consumer_keyoauth_signature_methodoauth_signatureoauth_timestampoauth_nonceoauth_version（步骤B）ServiceProvider返回RequeststToken:oauth_tokenoauth_token_secret(stepC)ConsumerredirectsUsertoServiceProvider(/oauth/1.0/authorize):oauth_tokenoauth_callback(stepD)ServiceProvider在用户授权后重定向UsertoConsumer:oauth_token(stepE)Consumer申请AccessToken(/oauth/1.0/access_token):oauth_consumer_keyoauth_tokenoauth_signature_methodoauth_signatureoauth_timestampoauth_nonceoauth_version(步骤F)ServiceProvider返回AccessToken:oauth_tokenoauth_token_secretOAuth1.0漏洞涉及两种Token，分别是RequestToken和AccessRequest授权者会先诱导攻击者申请Token，然后是自己的RequestToken用户授权攻击者的请求令牌。那么，对于回调地址的使用，有以下几种攻击方式：如果ServiceProvider没有对回调地址进行限制（应用的设置不限于同根域名），那么攻击者可以将oauth_callback设置为自己的自己的网址。如果Consumer不使用回调地址（桌面端或移动端APP），而是通过User手动复制粘贴RequestToken来完成授权，那么只要攻击者在User面前发起请求，User的Access可以获得令牌。OAuth1.0改进步骤B传递callback_url参数（代替获取授权的request_token步骤）。Consumer在申请RequestToken时，必须通过oauth_callback让回调参与签名，防止攻击者伪造回调。验证未授权的request_token后，返回新参数oauth_verifier。验证完成后，会返回验证码（oauth_verifier）。当没有回调的时候，服务商会展示给用户，然后用户在第三方应用的设备上输入，表示他已经被授权（和非授权用户分开），然后第三方-方应用必须添加验证码才能获取OAuth1.0a流程图OAuth2.0流程OAuth2.0定义了四种授权方式。授权码（authorizationcode）（本文只讲解授权方式）简化模式（implicit）密码模式（resourceownerpasswordcredentials）客户端模式（clientcredentials）接口（步骤A）Client向AuthorizationServer发送申请（/oauth/2.0/authorize):response_type=codeclient_idredirect_uriscopestate(stepB)ResourceOwner授权后AuthorizationServer返回codestate给Client(stepC)Client向AuthorizationServer(/oauth/2.0/token)发送申请:grant_type=authorization_codecodeclient_idclient_secrecredirect_uri(stepE)资源所有者授权后服务器返回访问令牌给客户端：access_tokentoken_typeexpires_inrefresh_token关于状态参数[状态参数的RFC解释]授权服务器应该要求客户端提供完整的重定向URI（客户端可以使用“state”请求参数实现per-要求定制）。如果要求注册完整的重定向URI是不可能的，授权服务器应该要求注册URI方案、权限和路径（允许客户端动态地请求授权时仅改变重定向URI的查询组件）。我们假设如下场景：(1)用户A登录第三方网站A后，到达绑定页面，尚未绑定微博。（2）绑定页面提供一个按钮：“绑定微博”（地址a：http://aaa.com/index.php?m=us...）（3）用户A点击地址a，程序生成以下地址b：https://api.weibo.com/oauth2/...【9999999】&redirect_uri=【http://aaa.comindex.php】&response_type=【code】(4)用户A的浏览器被定向到地址b.授权应用程序。(5)授权服务器根据传入的redirect_uri参数和组合的认证参数code生成地址c：http://aaa.comindex.php&code=【809ui0asduve】(6)用户A浏览器返回地址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://工具。ietf.org/html/r...《RFC 6749》结束语本文是对网上资料的总结。如有错误，请批评指正。如有侵权，请联系我删除文章。谢谢。有兴趣的同学也可以参考【微博OAuth】API，申请第三方应用，参考微博API实现一个获取access_token的测试用例（微博会给申请的第三方应用client_id，client_secret）
