本文以腾讯微博为例，详细介绍OAuth2.0的认证过程。
在使用腾讯微博平台提供的API前，您需要做以下两步工作：
- 成为开发者，并申请appkey和appsecret
- 授权获取accesstoken
Accesstoken是第三方获得用户授权的凭证，是第三方访问api资源的票据。目前，腾讯微博采用Oauth2.0协议对第三方进行授权，相对Oauth1.0来说，Oauth2.0具有更加简单和安全特点。
获取accesstoken的两种方式
用户通过Oauth2.0授权第三方有两种方式：
- Authorization code grant，适合于有server端的应用授权
- Implicit grant，适合于通过客户端访问的应用授权。如字，是永久的授权方式，虽说是永久的，但是AccessToken是有时限的。
Authorization cod模式和Implicit模式仅在授权的时候有所区别，后续调用API的方式是一致的。
1.Authorization code grant
使用场景：
Authorization code授权适用于PC，无线客户端等需要和第三方server进行交互的应用场景。使用Authorization code授权，第三方能够集中处理用户的授权请求和授权结果，适用于有server端的应用。
授权流程：
Authorization code授权模式分为两步，首先获取code，然后用code换取accesstoken。官方流程示意图：
三者的交互图：
第一步：请求code
请求方法：
GET
请求地址：
https://open.t.qq.com/cgi-bin/oauth2/authorize?client_id=APP_KEY&
response_type=code&redirect_uri=REDIRECT_URI
[[[[注]]]] 本文所有代码中的大写字母部分为需要用户自己填写的。
请求参数：
| 字段 | 必须 | 说明 |
|---|---|---|
| client_id | true | 申请应用时分配的app_key |
| redirect_uri | true | 授权回调地址，必须和应用注册的地址一致 |
| response_type | true | 授权类型，为code |
| wap | false | 主要用于指定手机授权页的版本，无此参数默认显示pc授权页面
wap=1时，跳转到wap1.0的授权页 |
| state | false | 用于保持请求和回调的状态，授权请求成功后原样带回给第三方。该参数用于防止csrf攻击（跨站请求伪造攻击），强烈建议第三方带上该参数。参数设置建议为简单随机数+session的方式 |
| forcelogin | false | 针对pc授权页 forcelogin=true，强制弹出登录授权页面 forcelogin=false，用户已经登录并且已经授权第三方应用，则不再弹出授权页面 默认为forcelogin=true |
返回结果：
如果授权成功，授权服务器会将用户的浏览器重定向到redirect_uri，并带上code，openid和openkey等参数，重定向的url如下：
http://www.myurl.com/example?code=CODE&openid=OPENID&openkey=OPENKEY
参数说明：
| 字段 | 说明 |
|---|---|
| code | 用来换取accesstoken的授权码，有效期为10分钟 |
| openid | 用户统一标识，可以唯一标识一个用户 |
| openkey | 与openid对应的用户key，是验证openid身份的验证密钥 |
第二步：请求accesstoken
https://open.t.qq.com/cgi-bin/oauth2/access_token?client_id=APP_KEY&
client_secret=APP_SECRET&redirect_uri=http://www.myurl.com/example&grant_type=authorization_code&code=CODE
请求参数：
| 字段 | 必须 | 说明 |
|---|---|---|
| client_id | true | 申请应用时分配的app_key |
| client_secret | true | 申请应用时分配的app_secret |
| grant_type | true | authorization_code |
| code | true | 调用authorize时返回的code |
| redirect_uri | true | 授权回调地址，必须和应用注册的地址一致 |
| state | false | 用于保持请求和回调的状态，授权请求成功后原样带回给第三方。该参数用于防止csrf攻击（跨站请求伪造攻击），强烈建议第三方带上该参数。参数设置建议为简单随机数+session的方式 |
返回结果：
access_token=ACCESS_TOKEN&expires_in=&refresh_token=REFRESH_TOKEN
参数说明：
| 字段 | 说明 |
|---|---|
| access_token | 访问第三方资源的凭证 |
| expires_in | accesstoken过期时间，以返回的时间的准，单位为秒，注意过期时提醒用户重新授权 |
| refresh_token | 刷新token |
2.Implicit grant
使用场景：
Implicit grant授权适用于没有server端的客户端应用，由客户端发起授权请求，保存和处理accesstoken。
授权流程：
官方流程示意图：
交互图:
请求地址：
https://open.t.qq.com/cgi-bin/oauth2/authorize?client_id=APP_KEY&
response_type=token&redirect_uri=http://www.myurl.com/example
请求参数：
| 字段 | 必须 | 说明 |
|---|---|---|
| client_id | true | 申请应用时分配的app_key |
| redirect_uri | true | 授权回调地址，必须和应用注册的地址一致 |
| response_type | true | 授权类型，为token |
| wap | false | 主要用于指定手机授权页的版本，无此参数默认显示pc授权页面
wap=1时，跳转到wap1.0的授权页 |
| state | false | 用于保持请求和回调的状态，授权请求成功后原样带回给第三方。该参数用于防止csrf攻击（跨站请求伪造攻击），强烈建议第三方带上该参数。参数设置建议为简单随机数+session的方式 |
| forcelogin | false | 针对pc授权页 forcelogin=true，强制弹出登录授权页面 forcelogin=false，用户已经登录并且已经授权第三方应用，则不再弹出授权页面 默认为forcelogin=true |
返回结果：
http://www.myurl.com/example#access_token=ACCESS_TOKEN&expires_in=60&openid=OPENID&openkey=OPENKEY
参数说明：
| 字段 | 说明 |
|---|---|
| access_token | accesstoken，访问api资源的凭证 |
| expires_in | accesstoken过期时间，以系统返回的过期时间为准，注意过期时提醒用户重新授权 |
| openid | 用户统一标识，可以唯一标识一个用户 |
| openkey | 与openid对应的用户key，是验证openid身份的验证密钥 |
刷新accesstoken
Oauth2中，access_token的有效期不是无限的，当第三方应用使用的access_token时间超过了其生命周期时，可以通过刷新机制来获取新的access_token。
https://open.t.qq.com/cgi-bin/oauth2/access_token?client_id=APP_KEY&
grant_type=refresh_token&refresh_token=REFRESH_TOKEN
请求参数
| 字段 | 必须 | 说明 |
|---|---|---|
| client_id | true | 申请应用时分配的app_key |
| grant_type | true | 固定为“refresh_token” |
| refresh_token | true | 上次授权或者刷新时获取的refresh_token |
返回结果
返回字符串：
access_token=ACCESS_TOKEN&expires_in=&refresh_token=REFRESH_TOKEN&name=NAME
参数说明
| 字段 | 说明 |
|---|---|
| access_token | access_token，访问api资源的凭证 |
| expires_in | access_token过期时间，以系统返回的过期时间为准，注意过期时提醒用户重新授权 |
| refresh_token | 刷新token |
| name | 授权用户微博帐号 |
注：
通过刷新机制可以延长access_token有效期，每次刷新延长的access_token有效期与授权时access_token的有效期一致，多次刷新可将access_token的有效期延长至一年。
总结：
OAuth的认证和授权的过程中涉及的三方包括：
服务商：用户使用服务的提供方。
用 户：服务商的用户
第三方：通常是网站，该网站想要访问用户存储在服务商那里的信息。
比如我现在正在开发一个访问新浪微博好友信息的客户端，现将其称之为Aita。
那么按照上面的介绍：
服务提供商：新浪微博
用户：就是我了，如果你使用我的客户端就是你了，总之就是我的客户端Aita的使用者。
第三方：就是我开发的这个客户端Aita
在认证过程之前，第三方需要先向服务商申请第三方服务的唯一标识。就是我要开发的这个客户端Aita首先需要在新浪的开发者平台注册一下获得一个Appkey。
OAuth认证和授权的过程如下:
1、我（用户）使用Aita(第三方)想看看我的好友发表了什么微博，然后顺便点个赞。
2、Aita(第三方向)首先向服务商(新浪微博)请求一个临时令牌。
3、服务商（新浪微博）验证第三方（Aita）的身份后，授予一个临时令牌（Code）。
4、第三方（Aita）获得临时令牌（Code）后，将用户导向至服务商的授权页面请求用户授权，然后这个过程中将临时令牌（Code）和第三方（Aita）的返回地址(回调地址)发送给服务商。
5、用户在服务商（新浪微博）的授权页面上输入自己的用户名和密码，授权第三方（Aita）访问所相应的资源（查看好友动态）。
6、验证成功后，服务商（新浪微博）将用户导向第三方（Aita）的返回地址(回调地址--是我在新浪开发者平台上填写的)。
7、第三方（Aita）根据临时令牌（Code）从服务商（新浪微博）那里换取访问令牌(AccessToken)。
8、服务商(新浪微博)根据令牌和用户的授权情况授予第三方（Aita）访问令牌。
9、第三方（Aita）使用获取到的访问令牌访问存放在服务商（新浪微博）的对应的用户资源。