1渴肉、什么是OAuth認證
OAuth（開放授權）是一個開放標準命咐，允許用戶讓第三方應用訪問該用戶在某一網站上存儲的私密的資源（如照片壹堰，視頻，聯(lián)系人列表）爬骤，而無需將用戶名和密碼提供給第三方應用充石。
例如，我自己的應用盖腕，希望使用用戶（比如*恒）github上面某些文件赫冬，此時，用戶同意我的應用使用github的文件溃列，但是同時劲厌，不希望告訴應用他的github賬戶和密碼，因為這樣會造成用戶的信息泄漏听隐。而OAuth正是為了解決這個問題的一個標準补鼻，允許用戶讓第三方應用訪問在某一網站上存儲的私密的資源（如照片，視頻雅任，聯(lián)系人列表）风范，而無需將用戶名和密碼提供給第三方應用。
2沪么、OAuth認證過程
1. 首先硼婿，我（應用提供者）。需要在github（隱私資源）中禽车，注冊自己的應用寇漫，此時要告知github刊殉，我的應用需要哪些權限。之后州胳，github 會提供給我一個client_id记焊，client_secret以及一個redirect_uri。
2. 認證過程栓撞。
用戶使用我的應用時遍膜，點擊獲取google drive照片席纽，或者使用google賬戶登陸的時候途样，我的應用會引導用戶進入github的授權界面（此界面時github提供，和我的應用沒有關系）告喊。用戶提供出client_id岭粤，github就知道用戶是從我的應用讓他過來惜索，然后他就把我需要的權限告知用戶特笋，并詢問用戶是否同意剃浇。
// 用戶登錄 github，協(xié)商
GET //github.com/login/oauth/authorize
// 協(xié)商憑證
params = {
client_id: "xxxx",
redirect_uri: "http://my-application.com"
}
如果此時用戶覺得我要求的太多猎物，這些權限不想給我虎囚，那么此時認證過程就此結束。如果用戶覺得ok蔫磨，點擊了授權淘讥，那么頁面會跳轉到預先設定的redirect_uri并且附帶一個蓋了同意章的code。
// 協(xié)商成功后帶著蓋了章的 code
Location: http://my-application.com?code=xxx
3. 告訴github堤如，我要來取數據了蒲列。
上一步中，我獲得了用戶蓋了同意章的code搀罢，但是蝗岖，這個code只能表明，用戶允許我從githhub上獲取數據榔至，但是同時還需要對我應用進行認證抵赢。此時需要使用client_secret。
// 網站和 github 之間的協(xié)商
POST //github.com/login/oauth/access_token
// 協(xié)商憑證包括 github 給用戶蓋的章和 github 發(fā)給我的門票
params = {
code: "xxx",
client_id: "xxx",
client_secret: "xxx",
redirect_uri: "http://my-website.com"
}
拿著用戶蓋過章的 code 和能夠標識個人身份的 client_id唧取、client_secret 去拜訪 github铅鲤，拿到最后的綠卡 access_token。
// 拿到最后的綠卡
response = {
access_token: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
scope: "user,gist"
token_type: "bearer",
refresh_token: "xxxx"
}
4. 訪問用戶數據
// 訪問用戶數據
GET //api.github.com/user?access_token=xxxxxxxxxxxxxxxx
之后就可以訪問用戶的數據了枫弟。
上一步 github 已經把最后的綠卡 access_token 給我了邢享，通過 github 提供的 API 加綠卡就能夠訪問用戶的信息了，能獲取用戶的哪些權限在 response 中也給了明確的說明淡诗，scope 為 user 和 gist骇塘，也就是只能獲取 user 組和 gist 組兩個小組的權限掸犬。
整個流程到這里就結束了。
3绪爸、例子
使用qq登陸豆瓣
之后就成功使用qq登陸了豆瓣湾碎。
整個過程十分簡單，對于用戶來說奠货，就是在豆瓣的網頁上登陸了使用qq登陸介褥，然后就可以正常使用豆瓣的功能了。
分析一下整個過程
簡單來說递惋，上述例子中的豆瓣就是客戶端柔滔，QQ就是認證服務器，OAuth2.0就是客戶端和認證服務器之間由于相互不信任而產生的一個授權協(xié)議萍虽。要是相互信任那QQ直接把自己數據庫給豆瓣好了睛廊，你直接在豆瓣輸入qq賬號密碼查下數據庫驗證就登陸唄，還跳來跳去的多麻煩杉编。
就這這張圖超全，來說一下上述例子中的三個步驟在圖中的表現(xiàn)。所用到的請求路徑名稱都是虛構的邓馒，所附帶的請求參數忽略了一些非重點的嘶朱。
第一步：在豆瓣官網點擊用qq登錄
當你點擊用qq登錄的小圖標時，實際上是向豆瓣的服務器發(fā)起了一個 http://www.douban.com/leadToAuthorize 的請求光酣，豆瓣服務器會響應一個重定向地址疏遏，指向qq授權登錄，瀏覽器接到重定向地址 http://www.qq.com/authorize?callback=www.douban.com/callback 救军，再次訪問财异。并注意到這次訪問帶了一個參數是callback，以便qq那邊授權成功再次讓瀏覽器發(fā)起這個callback請求唱遭。不然qq怎么知道你讓我授權后要返回那個頁面啊戳寸。
至于訪問這個地址之后，qq那邊做出怎樣的回應胆萧，就是第二步的事情了庆揩。總之第一步即對應了圖中的這些部分跌穗。
第二步：跳轉到qq登錄頁面輸入用戶名密碼订晌，然后點授權并登錄
上一步中瀏覽器接到重定向地址并訪問 http://www.qq.com/authorize?callback=www.douban.com/callback
qq的服務器接受到了豆瓣訪問的authorize，在次例中所給出的回應是跳轉到qq的登錄頁面蚌吸，用戶輸入賬號密碼點擊授權并登錄按鈕后锈拨，一定還會訪問qq服務器中校驗用戶名密碼的方法，若校驗成功羹唠，該方法會響應瀏覽器一個重定向地址奕枢，并附上一個code（授權碼）娄昆。由于豆瓣只關心像qq發(fā)起authorize請求后會返回一個code，并不關心qq是如何校驗用戶的缝彬，并且這個過程每個授權服務器可能會做些個性化的處理萌焰，只要最終的結果是返回給瀏覽器一個重定向并附上code即可，所以這個過程在圖中并沒有詳細展開」惹常現(xiàn)把展開圖畫給大家扒俯。
第三步：跳回到豆瓣頁面，成功登錄
用戶在QQ登錄頁面點擊授權登陸后一疯，就直接跳轉到豆瓣首頁了撼玄，但其實經歷了很多隱藏的過程。
首先接上一步墩邀，QQ服務器在判斷登錄成功后掌猛，使頁面重定向到之前豆瓣發(fā)來的callback并附上code授權碼，即 callback=www.douban.com/callback
頁面接到重定向眉睹，發(fā)起 http://www.douban.com/callback請求
豆瓣服務器收到請求后荔茬，做了兩件再次與QQ溝通的事，即模擬瀏覽器發(fā)起了兩次請求辣往。一個是用拿到的code去換token兔院，另一個就是用拿到的token換取用戶信息殖卑。最后將用戶信息儲存起來站削，返回給瀏覽器其首頁的視圖。到此OAuth2.0授權結束孵稽。
參考地址
