有兩家網際網路企業 a 和 b，其中 b 是一家提供相片雲儲存的公司。使用者可以把相片上傳到 b **上長期儲存，然後可以在不同的裝置上檢視。某一天，a 和 b 談成了一項合作：希望使用者在使用 a **時，也可以**他在 b 的相片。這個技術上要怎麼實現呢？
選項一：由 b 提供乙個介面：
get /photos?account=
引數：account ： b 賬號
返回：指定賬號下的所有相片
有了這個介面，a **只需在介面上顯示乙個輸入框，讓使用者輸入他的 b 賬號，然後呼叫這個介面來獲取相片就可以了。
這樣可行嗎？
no！為啥？
因為實現並開放這樣乙個介面，相當於直接把 b 公司的相片資源全部暴露在網際網路中，雖然並沒有公開，但是對於有點安全意識的技術人員來說，要發現這個介面簡直輕而易舉。這樣的話，b 的使用者就沒有任何隱私了。
那怎麼辦呢？這樣吧，為了保證不能隨便獲取別人的相片，我們把介面改成這樣：
get /photos?account=&pwd=
除了要求使用者輸入賬號，還要輸入密碼。只有當賬號密碼驗證通過，才返回該賬號下的所有相片。這樣，即使黑客發現了這個介面，他不知道使用者的密碼，所以沒辦法竊取使用者的相片了。這樣 ok 了吧？
答案還是 no！絕不可以這麼做！
為什麼？這裡涉及到乙個信任問題。如果這樣實現，那麼，使用者必須在 a 的**裡輸入他在 b 的賬號和密碼。如果你是乙個隱私意識很強的人，你很可能會問：「憑什麼我要把 b 的賬號密碼告訴 a ？」這裡，從使用者的角度就已經感受到一種不安全感，憑什麼讓我信任你 a，你保證不拿我的 b 賬號密碼去幹壞事？而更深一層次，站在 b 的角度來考慮的話，也是一樣的問題：我憑什麼絕對信任 a？如果 a 在接收到使用者的輸入之後，馬上就把請求發到我們這裡來，那是 ok 的。但是萬一 a 在這個過程偷偷把賬號密碼存起來了呢？那隨著時間的推移，a 就慢慢地蒐集到一大批 b 的賬號密碼！這對 b 來講，是不能接受的！
那怎麼辦呢？
我們分析一下這個問題產生的原因，主要是在於 a、b、使用者 三方的互動模型有問題。請看：
在這個場景下，使用者需要訪問他在 b 的相片資源，但是他不能直接和 b 打交道，而是必須通過 a。在這個前提下去考慮問題，無論如何無法想出乙個既能實現功能，又能讓使用者和 b 都感到放心的實現方案。
oauth2.0 就是為了解決這個問題而提出來的互動模型。它告訴人們，在這種場景下，三方要怎麼打交道，才能做到安全、合理。
具體來說，oauth2.0 的互動模型的核心是這個樣子的：
解釋一下幾個術語。
資源伺服器。即資源的存放地點，或者說資源的訪問入口。在例子中，資源伺服器即 get photos 介面所部署的伺服器。a 必須經由這裡去訪問資源。
鑑權伺服器。這是乙個對使用者的身份進行認證、並對 a 進行授權的地方。這也是 oauth2.0 的關鍵節點。通常情況下，鑑權伺服器也是屬於 b 公司的。
好，接下來看看整個互動過程是怎樣的。
首先，同樣是使用者在訪問 a 的**，然後，a 需要訪問 b 使用者的相片。這個時候，a 並不是展示乙個輸入框給使用者，而是開啟乙個頁面。這個頁面就是 b 部署在鑑權伺服器上面的乙個鑑權頁面，通常情況下，它長得類似下面這個樣子：
這個頁面有兩個要素：
2，展示了授權資訊。看頁面右方「有道雲筆記將獲得以下許可權」部分。這是在告訴使用者，如果你授權給 a，那麼，a 將獲得訪問你這些資源的許可權
注意，這個頁面是部署在 b 的鑑權伺服器上，所有使用者輸入的賬號密碼是直接提交給 b，a 是沒有任何機會拿到的。
如果使用者同意授權並且認證通過，那麼，接下來鑑權伺服器會通知 a，並給 a 傳送乙個訪問令牌（access token，其實就是一段全域性唯一的隨機字串）。有了這個訪問令牌，a 就可以拿著它去找資源伺服器要資源了。
所以，獲取相片的介面會是類似這個形式（實際當中不會把 access token 放在 query string 中，這裡做了簡化）：
get /photos?accesstoken=
資源伺服器在接收到這個請求之後，會拿著 access token，再去找鑑權伺服器，檢查這個 access token 的合法性和許可權，如果通過的話，才返回資源給 a。
如此，即實現了功能，也保障了安全性。不過你可能會問，這個 access token 和賬號密碼的區別是什麼呢？都是代表使用者身份的，為什麼 access token 就更安全？答案是：
1，賬號密碼是一切，有了賬號密碼就幾乎可以做任何事情（甚至改掉原密碼）。而 access token 是有限制範圍的。每個 access token 都有乙個 scope，也就是允許執行哪些操作。
2，access token 是有有效期的。如果 access token 被竊取，也不能一直用。
OAuth2 0的原理介紹
oauth2.0是乙個關於授權 authorization 的開放網路標準，在全世界得到廣泛應用，目前的版本是2.0版。授權碼模式 authorization code 簡化模式 implicit 密碼模式 resource owner password credentials 客戶端模式 clie...
OAuth 2 0 基本介紹
前言 最近討論園子裡是否真末落的話題那可是沸沸揚揚啊！我就不湊這個熱鬧了！在此吐點最近在整的東西出來給大家！廣大開發者和使用者登入平台後，就可以使用平台提供的開放api介面，建立應用從微博系統獲取資訊，或將新的資訊傳播到整個微博系統中，豐富多樣的api介面和應用，加上您的智慧型，將創造出無窮的應用和...
OAuth2 0 基礎介紹
1 應用場景 2 角色說明 3 oauth2.0 概述 4 協議流程 5 四種授權模式 6 授權碼模式 1 resource owner資源擁有者，能夠許可對受保護資源的訪問許可權的實體。當資源所有者是個人時，它被稱為終端使用者。2 resource server 資源伺服器，管理受保護資源的伺服器...