OAuth2.0认证过程

本文以腾讯微博为例，详细介绍OAuth2.0的认证过程。

在使用腾讯微博平台提供的API前，您需要做以下两步工作：

1. 成为开发者，并申请appkey和appsecret
2. 授权获取accesstoken

Accesstoken是第三方获得用户授权的凭证，是第三方访问api资源的票据。目前，腾讯微博采用Oauth2.0协议对第三方进行授权，相对Oauth1.0来说，Oauth2.0具有更加简单和安全特点。

获取accesstoken的两种方式

用户通过Oauth2.0授权第三方有两种方式：

1. Authorization code grant，适合于有server端的应用授权
2. 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的授权页 wap=2时，跳转到wap2.0的授权页  不带本参数时，手机访问默认跳到wap2.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=60&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的授权页 wap=2时，跳转到wap2.0的授权页  不带本参数时，手机访问默认跳到wap2.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=60&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）使用获取到的访问令牌访问存放在服务商（新浪微博）的对应的用户资源。