如果通過oauth訪問成功，網盤就可以從qq中獲取乙個名為access token的令牌。通過該token，便可訪問qq中使用者允許訪問的資訊。
oauth最主要的優點在於它是一種被廣泛認可的認證機制，並且已經實現了標準化。
其中resource owner password credential模式就是不存在**b，客戶端直接從使用者那裡得到密碼，並從伺服器a那裡獲取access token。這一授權模式就能夠應用在公司內部所開發的客戶端應用中。
示例：
post /v1/oauth2/token http/1.1
host: api.example.com
authorization: basic ************************x
grant_type=password&username=zhang&password=zhang&scope=api
複製**
複製**
token_type中的bearer是rfc6750中定義的oauth2.0所用的token型別。access_token是以後訪問時所需的access token。在以後訪問api時，只需附帶傳送該token資訊即可。這時無需再次傳送clientid和clientsecret資訊了。因為各個不同的客戶端都會從伺服器端得到特定的access token，即使之後沒有clientid，服務端也同樣可以用access token資訊來識別應用身份。
根據rfc6750的定義，客戶端有3種方法將bearer token資訊傳送給伺服器端：
新增到請求資訊的首部
新增到請求訊息體
以查詢引數的形式新增到url中
1、將token資訊新增到請求訊息的首部時，客戶端要用到authorization首部，並按下面的形式指定token的內容：
複製**
複製**
3、以查詢引數的形式新增token引數時，可以在名為access_token的查詢引數後指定token資訊。
複製**
客戶端在獲得access token的同時也會在響應資訊中得到乙個名為expires_in的資料，它表示當前獲得的access token會在多少秒以後過期。當超過該指定的秒數後，access token便會過期。當access token過期後，如果客戶端依然用它訪問服務，服務端就會返回invalid_token的錯誤或401錯誤碼。
複製**
當發生invalid_token錯誤時，客戶端需要使用refresh token再次向服務端申請access token。這裡的refresh token時客戶端再次申請access token時需要的另乙個令牌資訊，它可以和access token一併獲得。
在重新整理access token的請求裡，客戶端可以在grent_type引數裡指定refresh_token，並和refresh_token一起傳送給伺服器端。
複製**
utils/oauth.js
const tokenkey = 'access_token'
const expireskey = 'expires_in'
const tokentypekey = 'bearer'
const refreshtokenkey = 'refresh_token'
export function gettoken ()
export function getrefreshtoken ()
export function settoken (data)
export function removetoken ()
複製**
import axios from 'axios'
import vue from 'vue'
import from '@/utils/oauth'
const server = axios.create()
// 用於記錄是否正在重新整理token，以免同時重新整理
window.tokenlock = false
function refreshtoken () ) => )
window.tokenlock = true
}}server.interceptors.request.use(req => $`
return req
}, error => )
server.interceptors.response.use(rep =>
} return rep
}, error => )
return
}removetoken()
location.reload()
} return promise.reject(error)
})export default server
複製**
Oauth2 0與Oauth1 0的區別
oauth1.0與oauth2.0的區別 雲計算的熱火，引出了大量的開放平台，各種第三方應用建立在開放平台之上，對於安全性的要求，於是出現了oauth協議，2007年發布了oauth1.0協議，同時又開始了oauth2.0的討論，2.0的草案與2011年發布。新的2.0與1.0不相容。下面說一說2....
oAuth 2 0協議解析
部落格 完整的oauth 2.0協議流包括4個主體，6個步驟。4個主體分別是 資源擁有者 可以是人，負責授權工作。對open api來說，即發布方。發布方審批呼叫者的申請，通過後，即完成授權，體現為資料庫中的記錄。客戶端 一般是第三方應用程式。對於open api來說，即呼叫者。授權伺服器 負責完成...
OAuth 2 0系列教程
作者 jakob jenkov譯者 林浩校對 郭蕾 oauth是openid的乙個補充，但是完全不同的服務。oauth 2.0 是目前比較流行的做法，它率先被google,yahoo,microsoft,facebook等使用。之所以標註為 2.0，是因為最初有乙個1.0協議，但這個1.0協議被弄得...