以前最烦的就是xx和我说你咋不支持OAuth啊？那是标准啊，多通用啊？同学，标准是啥？中国还有个馒头标准，直径大于多少还不算是馒头呢！其实早在我做开放平台时，OAuth的确实有了，但是当时也就是个草案，不过也是一群大牛公司的人在那儿捣鼓，但是当时没有一个真正的开放平台大牛公司的人在做这个（我认为雅虎系是当时最早一批做开放平台的）。
前几天在微博上发了三张OAuth2的手写草稿（具体可以看看t.sina.com/fangweng），其实也是为了今天在内部产品和研发小范围分享OAuth2的优势，同时也对将来淘宝开放平台授权从单应用授权到将来多平台互通做准备。OAuth1我现在依旧保持自己的看法，没觉得有什么优势在！但是，今天来看OAuth2的这些人（都是实实在在的做开放平台的人）制定的标准，可以发现它的设计缘由和优势，这里不谈OAuth2的流程，就说说几个小变化，这几个小变化直接决定了整个流程的差异化。
在OAuth2流程中有2个载体，3个过程，4个角色：
两个载体：
Authorization Code， Access Token（refresh token）
三个过程：
用户认证，应用认证，用户授权
四个角色：
用户，应用，授权服务器，资源服务器
第一个改变发生在角色的拆分：将授权服务器和资源服务器拆分开来。将授权与资源访问的宿主由一一对应变成了一对多的方式，只要资源访问能够验证授权，那么任何授权服务点都可以成为该类资源的授权中心。其实也是为多种平台间互联互通技术的提供更灵活的支持，另一方面针对不同终端的授权也可以定制化流程，只要最终授权流程得到的结果可以被资源提供者所认可就行。
第二个改变发生在获取Access Token的过程，简化了一次交换Token的流程。我至今还不是很清楚折腾反复那么多次交换的用处。
第三个，对于Agent和Client的模式有了更明确的流程支持。C/S模式和纯JS模式都是没有一个可以推送授权结果服务端的问题，现在流程中利用在URL参数中增加#在带上业务参数不会被302从定向提交给服务端来解决安全性和数据获取的问题。
第四个，提高开发者的授权开发门槛，降低开发服务请求门槛。可以想象的到授权本身的调用量和使用比例要远小于服务调用量。原先对于三个过程中的应用认证主要发生在服务调用中，每次调用都要对参数作签名（由于参数的复杂性及调用次数很多，入口很多，导致开发查错难），而现在应用认证和用户授权都发生在授权流程中，完全剥离了资源访问者对应用认证的处理，增加了授权开发成本，却降低了服务调用成本。（其实这种设计大量被用在前后端设计优化中）
另一些小细节也显示出了这是开放平台人做的标准：CSRF攻击的预防（增加了State字段），允许应用身份登陆（操作一些应用相关的平台型服务），scope来扩展业务访问控制范围，expires time表示Token的有效期（原来都是无限长时间的）
同时电子商务网站与SNS网站还是在安全性上有些差异，同时服务的控制方面也有不同，因此在资源提供者这段也会有一些附加的控制策略在，通过OAuth2的一些扩展点来更加细化控制。总的一句话：如果只知道Follow规范而不知道规范为什麽这么设计，那么还是不要鼓吹什么标准。不然就和馒头标准一样，说出来也就是个笑话。