因为新浪的Oauth即将变成2.0，所以找找资料
老王更新了，还画了ascii图，说实话我是对他文中的那个画ascii图的视频有兴趣。。。
老王在博客里是这么介绍的：
OAuth2.0
OAuth1.0虽然在安全性上经过修补已经没有问题了，但还存在其它的缺点，其中最主要的莫过于以下两点：其一，签名逻辑过于复杂，对开发者不够友好；其二，授权流程太过单一，除了Web应用以外，对桌面、移动应用来说不够友好。
为了弥补这些短板，OAuth2.0做了以下改变：
首先，去掉签名，改用SSL（HTTPS）确保安全性，所有的token不再有对应的secret存在，这也直接导致OAuth2.0不兼容老版本。
其次，针对不同的情况使用不同的授权流程，和老版本只有一种授权流程相比，新版本提供了四种授权流程，可依据客观情况选择。
在详细说明授权流程之前，我们需要先了解一下OAuth2.0中的角色：
OAuth1.0定义了三种角色：User、Service Provider、Consumer。而OAuth2.0则定义了四种角色：Resource Owner、Resource Server、Client、Authorization Server：
- Resource Owner：User
- Resource Server：Service Provider
- Client：Consumer
- Authorization Server：Service Provider
也就是说，OAuth2.0把原本OAuth1.0里的Service Provider角色分拆成Resource Server和Authorization Server两个角色，在授权时交互的是Authorization Server，在请求资源时交互的是Resource Server，当然，有时候他们是合二为一的。
－－－－－－－
当然，我这里CP的不全，更详细的请看：http://huoding.com/2011/11/08/126
如果不把ascii图CP过来，老王是不是很伤心？
哈哈，好象失败了。。。这是第二次CP的。希望成功
- +----------+
- | resource |
- | owner |
- | |
- +----------+
- ^
- |
- (B)
- +----|-----+ Client Identifier +---------------+
- | -+----(A)-- & Redirection URI ---->| |
- | User- | | Authorization |
- | Agent -+----(B)-- User authenticates --->| Server |
- | | | |
- | -+----(C)-- Authorization Code ---<| |
- +-|----|---+ +---------------+
- | | ^ v
- (A) (C) | |
- | | | |
- ^ v | |
- +---------+ | |
- | |>---(D)-- Authorization Code ---------' |
- | Client | & Redirection URI |
- | | |
- | |<---(E)----- Access Token -------------------'
- +---------+ (w/ Optional Refresh Token)
OK，还有一篇介绍 ：http://hueniverse.com/2010/05/introducing-oauth-2-0/
6 New Flows
- User-Agent Flow – for clients running inside a user-agent (typically a web browser).
- Web Server Flow – for clients that are part of a web server application, accessible via HTTP requests. This is a simpler version of the flow provided by OAuth 1.0.
- Device Flow – suitable for clients executing on limited devices, but where the end-user has separate access to a browser on another computer or device.
- Username and Password Flow – used in cases where the user trusts the client to handle its credentials but it is still undesirable for the client to store the user’s username and password. This flow is only suitable when there is a high degree of trust between the user and the client.
- Client Credentials Flow – the client uses its credentials to obtain an access token. This flow supports what is known as the 2-legged scenario.
- Assertion Flow – the client presents an assertion such as a SAML assertion to the authorization server in exchange for an access token.
Native application support (applications running on a desktop or mobile device) can be implemented using many of the flows above.
－－－－其实看起来就很纠结，反正先了解一下，refresh_token还得向新浪申请。真纠结