接着昨天的内容 OAuth的其实今生 说一下OAuth 2.0的事，OAuth 2.0的草案原本在2010年就会定稿，由于存在分歧，又经过三年的不断变更，当时草案的首席编辑伊兰（昨天提到写博客喷OAuth 2.0的人）渐渐发现OAuth 2.0已经被改得烂透了：复杂不说还没用，不完整也不安全。
OAuth 2.0不再是协议，而像是一个框架，它允许实现进行比较自由的扩展，伊兰同学认为这会导致OAuth被实现得五花八门难以控制，牛人会把OAuth 2.0实现的很安全，而让一般人实现恐怕会漏洞百出。对于伊兰的激烈反对，有人指出伊兰对草案的编辑权有过于强烈的控制欲，这才是导致分歧的关键。后来伊兰反驳说完全是误解，额，越来越像宫廷戏的狗血情节了。
OAuth 2.0标准编辑背后激烈斗争的同时，Facebook和Google已经将他们基于OAuth 2.0的授权认证体系实现出来了，他们的实现看起来足够完善，正好给业界树立了正确的典范，这一点伊兰也表示过赞同。
2012年10月，OAuth 2.0进入RFC建议标准阶段，其他相关的协议也在编写中，现在大多数授权都采用或者建议升级到OAuth 2.0。
下面开始说点细节。
应用注册
在使用使用平台的OAuth 2.0授权前，第三方应用必须到平台上进行注册，注册过程中可能需要填写的内容有：应用类型，授权成功回调地址，以及其他平台需要的资料（应用名称、网址、介绍、LOGO图片等）。OAuth 2.0标准主要围绕三类应用：Web应用、基于客户端的应用、原生应用。
应用注册完成会得到一个应用标识码和一个密钥，在国内几大平台的实现中，识别码一般叫 App Key，密钥叫 App Secret。这两样东西作用跟用户名密码是一样的。
OAuth 2.0 RFC中提到的授权方式有四种：授权码（Authorization Code）、隐式授权（Implicit Grant）、用户口令（Resource Owner Password Credentials）、应用口令（Client Credentials），跟1.0相比更丰富了（也可以说更复杂了），体现了OAuth 2.0解决更多设备和场景授权的思考。下面会对这四种方式逐一介绍，请大家记住一点，这四种方式最终的目的都是要获得 Access Token，应用拿到这个Token就可以直接请求资源了。
用户口令授权流程（Resource Owner Password Credentials）
用户直接把自己的用户名密码交给第三方应用，相当于委托应用实现一些操作，这只针对大型、可靠的应用，普通开发者基本不用考虑，这里不做介绍了。
应用口令授权流程（Client Credentials）
平台允许应用通过自己申请的App Key和App Secret获取资源，而能获取到的资源有限制，要么是应用自己创建的，要么是不需要权限的开放资源。这种方式比较简单这里也不做介绍。
授权码授权流程（Authorization Code）
此又称为 Server-side Flow，需要应用有Server端配合。为了便于理解，这里以淘宝开发平台OAuth授权为例，并且每个步骤都有截图，截图来自我做的一个Demo页面：
首先，引导用户到淘宝授权页面。要确保请求URL中必须设置三个参数：client_id（App Key），redirect_uri（授权回调页面），response_type（’code’）。这三个参数如下：
特别说明一点OAuth 2.0文档中请求授权页面时，redirect_uri参数并不是必选的，但是几乎所有平台实现时都要求此参数必选，这是出于安全考虑。
上面URL请求到的授权页面如下：
注意页面顶部有应用和授权说明，用户在这个淘宝的页面输入账号密码登录并授权后，页面跳转到redirect_uri参数中指定的回调地址：
http://www.noahlu.com/oauth/auth_code.php?code=jjBjAsnOI5kAp640FjFKeGhC1114627
注意到这个URL里有一个code参数，其值即为授权码。接下来就可以请求 Access Token，请求时需要发送一个POST请求（一般由应用后台Server来发这个请求），请求必须带5个参数：client_id，client_secret（App Secret），grant_type（’authorization_code’），code（刚刚获得的授权码），redirect_uri：
POST请求返回一陀JSON格式的数据：
其中标红的就是Access Token，拿到它说明授权成功，这里的其他参数不再做详细介绍，有兴趣的同学可以到「原文」中看参考文献。
说明一点，Access Token是如此的重要，以至于没人会像上图例子中那样把它在页面打印出来，在授权码流程中是后台来处理和保存的。
隐式授权流程（Implicit Grant）
上面花这么大力气讲授权码流程，只要你看懂了它，那隐式授权流程就很容易理解了。隐式授权又称为 Client-side Flow，不需要Server端，浏览器插件的首选。其实隐式授权相当于授权码流程的简化版，还是以淘宝为例：
先请求淘宝授权页面，有两个参数必选：client_id和response_type
https://oauth.taobao.com/authorize?client_id=21448925&state=taobao&response_type=token
用户授权后，跳转到淘宝中间页面，URL如下：
从URL中可以获取参数Access Token。
说明一下，OAuth 2.0标准中，redirect_uri时可选的。而不同平台实现略有不同：淘宝开发平台redirect_uri可以留空，留空的时，授权完成会跳转到一个淘宝的中间页面，页面url带access_token参数。百度开发平台不能留空，但可以设置为’oob’，当值为’oob’时，授权完成跳转到百度中间页面，跟淘宝类似。新浪微薄开发平台你可以手动设置应用的redirect_uri为微薄的中间页面。不得不说新浪微薄实现的太偷懒了。
参考资料
本站文章均由远尘原创，转载请注明：
转载自前端网事博客，本文链接地址:OAuth 2.0 实用指南