oauth2.0是什麼——豆瓣和qq的故事
oauth簡單說就是一種授權的協議，只要授權方和被授權方遵守這個協議去寫**提供服務，那雙方就是實現了oauth模式。
第一步：在豆瓣官網點選用qq登入
第二步：跳轉到qq登入頁面輸入使用者名稱密碼，然後點授權並登入
第三步：跳回到豆瓣頁面，成功登入
這幾秒鐘之內發生的事情，在無知的使用者視角看來，就是在豆瓣官網上輸了個qq號和密碼就登入成功了。在一些細心的使用者視角看來，頁面經歷了從豆瓣到qq，再從qq到豆瓣的兩次頁面跳轉。但作為一群專業的程式設計師，我們還應該從上帝視角來看這個過程。
oauth2.0是什麼——上帝視角
簡單來說，上述例子中的豆瓣就是客戶端，qq就是認證伺服器，oauth2.0就是客戶端和認證伺服器之間由於相互不信任而產生的乙個授權協議。呵呵，要是相互信任那qq直接把自己資料庫給豆瓣好了，你直接在豆瓣輸入qq賬號密碼查下資料庫驗證就登陸唄，還跳來跳去的多麻煩。
先上一張圖，該圖描繪了只幾秒鐘發生的所有事情用上帝視角來看的流程
就這這張圖，來說一下上述例子中的三個步驟在圖中的表現。所用到的請求路徑名稱都是虛構的，所附帶的請求引數忽略了一些非重點的。
第一步：在豆瓣官網點選用qq登入
當你點選用qq登入的小圖示時，實際上是向豆瓣的伺服器發起了乙個 的請求，豆瓣伺服器會響應乙個重定向位址，指向qq授權登入
瀏覽器接到重定向位址 ，再次訪問。並注意到這次訪問帶了乙個引數是callback，以便qq那邊授權成功再次讓瀏覽器發起這個callback請求。不然qq怎麼知道你讓我授權後要返回那個頁面啊，每天讓我授權的像豆瓣這樣的**這麼多。
至於訪問這個位址之後，qq那邊做出怎樣的回應，就是第二步的事情了。總之第一步即對應了圖中的這些部分。
第二步：跳轉到qq登入頁面輸入使用者名稱密碼，然後點授權並登入
上一步中瀏覽器接到重定向位址並訪問
qq的伺服器接受到了豆瓣訪問的authorize，在次例中所給出的回應是跳轉到qq的登入頁面，使用者輸入賬號密碼點選授權並登入按鈕後，一定還會訪問qq伺服器中校驗使用者名稱密碼的方法，若校驗成功，該方法會響應瀏覽器乙個重定向位址，並附上乙個code（授權碼）。由於豆瓣只關心像qq發起authorize請求後會返回乙個code，並不關心qq是如何校驗使用者的，並且這個過程每個授權伺服器可能會做些個性化的處理，只要最終的結果是返回給瀏覽器乙個重定向並附上code即可，所以這個過程在圖中並沒有詳細展開。現把展開圖畫給大家。
第三步：跳回到豆瓣頁面，成功登入
這一步背後的過程其實是最繁瑣的，但對於使用者來說是完全感知不到的。使用者在qq登入頁面點選授權登陸後，就直接跳轉到豆瓣首頁了，但其實經歷了很多隱藏的過程。
首先接上一步，qq伺服器在判斷登入成功後，使頁面重定向到之前豆瓣發來的callback並附上code授權碼，即 callback=www.douban.com/callback
頁面接到重定向，發起 請求
豆瓣伺服器收到請求後，做了兩件再次與qq溝通的事，即模擬瀏覽器發起了兩次請求。乙個是用拿到的code去換token，另乙個就是用拿到的token換取使用者資訊。最後將使用者資訊儲存起來，返回給瀏覽器其首頁的檢視。到此oauth2.0授權結束。
OAuth2 單點登入
簡介 oauth open authorization 是乙個開放標準，允許使用者授權第三方應用訪問他們儲存在另外的服務提供者上的資訊，而不需要將使用者名稱和密碼提供給第三方應用。oauth2是oauth協議的延續版本，oauth1已經被廢棄，現在oauth2是用於授權的行業標準協議。1.四個角色 ...
SSO單點登入之OAuth2 0登入認證
client 呼叫資源伺服器api的應用 oauth 2.0 provider 包括authorization server和resource server 1 authorization server 認證伺服器，進行認證和授權 2 resource server 資源伺服器，保護受保護的資源 u...
SSO單點登入之OAuth2 0登入認證
一 oauth中的角色 client 呼叫資源伺服器api的應用 oauth 2.0 provider 包括authorization server和resource server 1 authorization server 認證伺服器，進行認證和授權 2 resource server 資源伺服...