oauth2.0及微信中oauth2.0的运用

##1. 理解OAuth2.0
首先我们通过一张图片来了解一下OAuth2.0的运作模式：
![此处输入图片的描述][1]

从上图我们可以看到，整个过程进行了2次“握手”，最终利用授权的AccessToken进行一系列的请求，相关的过程说明如下：

> A：由客户端向服务器发出验证请求，请求中一般会携带这些参数
ID标识，例如appId
验证后跳转到的URL（redirectUrl）
状态参数（可选）
授权作用域scope（可选）
响应类型（可选）
B：服务器返回一个grant授权标识（微信默认情况下称之为code），类似于一个一次性的临时字符串密钥。如果在A中提供了redirectUrl，这里服务器会做一次跳转，带上grant和状态参数，访问redirectUrl。
C：客户端的redirectUrl对应页面，凭借grant再次发起请求，这次请求通常会携带一些敏感信息：
ID标识
密码
grant字符串（code）
grant类型（可选，微信中默认为code）
D：服务器验证ID标识、密码、grant都正确之后，返回AccessToken（注意，这里的AccessToken和之前通用接口、高级接口介绍的AccessToken没有关系，不能交叉使用）
E：客户端凭借AccessToken请求一系列的API，在此过程中不再会携带appId，Secret，grant等敏感的信息。
F：服务器返回请求结果。

##2. 微信的OAuth2.0使用

了解了OAuth2.0的基本原理之后，我们来看一下OAuth2.0在微信中是如何运用的。

　　假设一个场景：用户进入了一个微信公众账号，随后通过消息中的链接，在微信内嵌浏览器中打开了一个游戏网页，这个游戏需要用户登录并且记录用户的游戏得分。

　　这种情况下我们有两种处理方式：

>* 让用户在网页中进行注册、登录（并且每次打开这个网页都可能要重新进行登录，因为微信内置浏览器的cookie保存时间非常短），这个当然是个很坑爹的设计。
>* 利用OAuth2.0。在用户进入这个页面的时候，先判断用户是否登录，如果没有，自动跳转到OAuth2.0授权页面，这个页面又自动进行了上述ABCD一系列验证，再通过EF得到用户的OpenId甚至更加详细的信息（包括头像），自动完成登录（或必要的注册）过程，随后用户以登录状态直接进入游戏。
　　可以看出，使用OAuth2.0大幅度提高了用户体验，并且可以自动绑定识别用户微信OpenId。

　　需要注意的是，上面提到的“OAuth2.0授权页面”还有两种形式：

>* 当请求A中的Scope为snsapi_base时，整个授权过程自动完成，用户的客户端不会有任何中间页面显示，但是授权的结果仅能获取用户的OpenId（不管用户是否已关注，当然如果用户是关注用户，再次利用高级接口中的用户信息接口，利用OpenId获取用户资料也是可以的，只不过绕了几个弯）
>* 当请求A中的Scope为snsapi_userinfo时，需要提供一个授权页面（类似很多网站利用微博账号、QQ号登陆的那种授权），仅当用户同意之后，立即获取到用户的详细信息，这里的用户可以是关注用户，也可以是未关注用户，返回的内容一致。

　　也就是说，snsapi_base的方法可以“神不知鬼不觉”地获取用户OpenId，全自动完成登录注册过程，但是信息量有限；snsapi_userinfo需要用户在指定界面上授权之后，自动完成整个过程，这个授权有一个时间段，超过时间后需要重新询问用户。

备注：文章来自网络。原文链接如下：　　
[原文链接][2]

  [1]: http://images.cnitblog.com/i/28384/201406/021337520528519.jpg
  [2]: http://www.cnblogs.com/szw/p/3764275.html​