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授權結束孵稽。
參考地址