作为一个第三方应用，用户通过微信登录应用，应用方想获取用户的一些私密信息，如微信头像和微信昵称等。此时，有两种不同的开发方案：
方案1：用户在第三方应用输入微信号和密码，应用方直接通过微信号和密码向微信服务器请求具体的信息。（显然是不现实的，微信也不会允许）
方案2：通过OAuth 2.0验证方案，在第三方应用不知道用户密码甚至微信账号信息的情况下获取需要的信息。
2. 什么是OAuth 2.0？
OAuth 2.0中O代表的是Open，开放；Auth代表的是Authenticate和Authorize，即验证和授权。涉及到的关键参与方有以下四个：
resource owner：对应着OAuth 1.0中的 User 角色，授权过程中的主体。
client：对应着OAuth 1.0中Consumer 的概念，通过申请获得resource owner的授权，从而实现访问受保护资源的第三方的软件或者服务，是授权过程中的客体。
resource server ：存储着resource owner的受保护资源的服务器，可以通过验证access token来开放对resource owner的数据的访问。
authorization server：在resource owner授权完毕后，负责颁发access token 的服务器。（实际项目中，resource server和authorization server可能部署在一台服务器上，甚至根本就是一套服务进程。）
（A）：客户端请求资源所有者的授权。
（B）：资源所有者同意授权。
（C）：客户端获得了资源所有者的授权之后，向授权服务器申请授权令牌。
（D）：授权服务器验证客户端无误后发放授权令牌。
（E）：客户端拿到授权令牌之后请求资源服务器发送用户信息。
（F）：资源服务器验证令牌无误后将用户信息发放给客户端。
授权码模式（authorization code）
简化模式（implicit）
密码模式（resource owner password credentials）
用户端模式（client credentials）
response_type：必选，请求类型。这里固定为"code"。
client_id：必选，标识第三方应用的id。很多地方也用apppid来代替。
redirect_uri：可选，授权完成后重定向的地址。当取得用户授权后，服务将重定向到这个地址，并在地址里附带上授权码。
scope：可选，第三方请求的资源范围。比如是想获取基本信息、敏感信息等。
state：推荐，用于状态保持，可以是任意字符串。授权服务会原封不动地返回。
C步骤，第三方应用拿到授权请求的response：资源所有者同意授权第三方应用访问受限资源后，请求返回，跳转到 redirect_uri 指定的地址。返回body有：
code：必选，授权码。后续步骤中，用来交换access token。
state：必选（如果授权请求中，带上了state），这里原封不动地回传。
D步骤，第三方应用继续请求access token：第三方应用向授权服务请求获取access token。请求参数包括：
grant_type：必选，许可类型，这里固定为“authorization_code”。
code：必选，授权码。在用户授权步骤中，授权服务返回的。
redirect_uri：必选，如果在授权请求步骤中，带上了redirect_uri，那么这里也必须带上，且值相同。
client_id：必选，第三方应用id。
access token：访问令牌，第三方应用访问用户资源的凭证。
access_token_expires_in：access token的有效时长。
refresh token：更新access token的凭证。当access token过期，可以refresh token为凭证，获取新的access token。
refresh_token_expires_in：refresh token的有效时长。
应用登录请求步骤和携带参数：
appid：应用id，就是前面提到的client_id。
redirect_uri：授权回调的地址，在微信管理后台填写。
response_type：响应类型，固定为"code"。
scope：授权许可范围，固定为"snsapi_login"。
state：可选，授权服务回传。
appid：必选，应用id。
secret：必选，应用秘钥，在微信后台生成。
code：必选，前面获取的授权码。
grant_type：必选，值固定为"authorization_code"
https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code
若access_token已超时，那么进行refresh_token会获取一个新的access_token，新的超时时间；
若access_token未超时，那么进行refresh_token不会改变access_token，但超时时间会刷新，相当于续期access_token。
refresh_token拥有较长的有效期（30天），当refresh_token失效的后，需要引导用户重新登录授权，获取新的refresh_token。
特别注意：对于授权码和access_token的篡改，在OAuth 1.0中是反复的对Code和Token进行签名，来保证Token不会被篡改，但是OAuth 2.0中却没有，因为OAuth 2.0是基于Https的，所以如果没有Https的支持OAuth 2.0可能还不如OAuth 1.0。在 OAuth 2.0 中，使用 HTTPS 可以说是必须的，而且 client 有义务验证证书的真假，防止中间人攻击，而 authorization server 和 resource server 都有义务申请可信任的第三方颁发的真实的 SSL 证书。
