oauth2.0是一套標準. 一、問題 這個標準解決了這樣的一個問題.

允許使用者讓第三方應用訪問該使用者在某一網站上儲存的私密的資源（如照片，視訊，聯絡人列表），而無需將使用者名稱和密碼提供給第三方應用。

第三方應用--比如一個繪圖的小軟體"paint" 訪問使用者--比如"我的qq空間賬號ws" 私密資訊--比如我qq空間中的照片 資源服務方-qq空間 認證伺服器-qq空間 正常情況下,要訪問使用者ws的qq中的照片, 需要將賬號和密碼傳送到qq空間的認證伺服器驗證身份. 但是第三方應用要訪問, 怎麼辦呢? 把賬號密碼告訴第三方應用paint,肯定不行

這就相當於把密碼告訴別人,而且還是我不認識的人.不安全. paint只需要一個照片,但把密碼都給他了,他連我的日記都能看了. paint如果把密碼公開或者洩露給別人的,那我怎麼辦.

二、解決

oauth2.0是怎麼解決的呢?

給第三方應用paint一個臨時密碼,過期作廢,而且這個密碼的訪問許可權可由我隨時取消.這樣就足夠安全了. 這個臨時密碼就是access_token. 當然發放access_token的方法就多種多樣了,這些方法叫做授權模式 授權模式一共四種: 1.客戶端模式(Client Credentials) 2.密碼模式(User Credentials) 3.簡化模式(Implicit) 4.授權碼模式(Authorization Code) 三、授權模式 1.客戶端模式(Client Credentials) 這是最簡單的一種方式, 不需要得到使用者ws授權,只要資源服務方qq空間對第三方應用paint發放一個client_id和client_secret,  第三方應用訪問資源時通過剛才的id和secret進行驗證後即返回access_token. 當然,這樣對使用者ws有些不公平,但實際上,在第三方應用paint所訪問的資源與使用者ws關係不大時就比較方便了. 此時,paint能從qq空間獲取任意圖片,只需要向qq空間認證,因為這些圖片與具體某個使用者無關.
2.密碼模式(User Credentials) 使用者ws將自己的使用者名稱密碼直接告知第三方應用paint, paint即可使用這個密碼向資源服務方qq空間獲取圖片. 這個方法就是剛才說過的很不安全的方法.但仍然有其適用的範圍. 就是在使用者ws與第三方應用paint更相熟情況, 也就是ws完全信任paint,放心的把密碼交給paint使用. 此時,paint僅能獲取使用者ws的圖片, 不能獲取ws2,ws3等使用者的圖片,所以paint一定要取得ws的信任拿到密碼. 3.簡化模式(Implicit) paint要得到access_token並且,不必知道ws的具體密碼. paint會訪問qq空間某一api介面時,告知client_id, user_id,qq空間收到請求後將頁面跳轉到認證頁面, 然後瀏覽器跳轉至qq空間的認證頁面,使用者ws在此頁面輸入使用者名稱密碼,在qq空間認證成功後. qq空間將瀏覽器跳轉到paint提前指定的url上,傳入access_token. 這時paint即可得到access_token. 注: 這裡的access_token如何能被paint得到? 就是解析redirect_url的引數. 比如這樣 ,直接取參考得到access_token為abcdefg.

http://my.redirect_url.com?access_token=abcedfg

像一些移動應用的程式內部實現時,即時一個錯誤的地址,也能解析到access_token. 因為應用內部會收到302跳轉的資料只要,從中解析到token後,不執行跳轉動作即可. 這個問題,困惑了我好久.經過朋友幫助才終於理解.   4.授權碼模式(Authorization Code) 授權碼模式與簡化模式的過程是一樣的. 不同之處在於,qq空間跳轉到paint的redirect_url時,不直接返回access_token,而是返回一個code. paint需要再將code發到qq空間,請求對應的access_token. 為什麼要多此一舉?  簡化模式適用於paint是移動客戶端應用的情況, 這個應用請求access_token後, 可直接獲取到access_token.並且這個access_token是在url引數後的. 也就是如果客戶端顯示的網址,就能看見access_token. 此時access_token是相對公開的不安全. 而授權碼模式適用於paint是移動客戶端應用,而且擁有自己的公網伺服器, 那麼它可以在請求到access_token時, 首先是公網伺服器(通過redirect_url)得到code, 由公網伺服器使用code請求access_token. 這時paint的公網伺服器直接向qq空間請求照片,然後再將照片轉發到paint移動客戶端應用. 整個過程客戶端是沒有得到access_token的.相對來說更安全. 授權碼模式時序圖（引用自

騰訊） (user: 使用者ws     App:第三方應用paint     Auth_svr:認證伺服器,qq空間)   四、總結 上面就是自己的淺見,本人實踐過程僅搭建了一個簡單的OAuth2.0伺服器,用於其他合作伙伴訪問我們的api時進行許可權認證. 是一個比較簡單的應用. 在學習理解OAuth2.0過程,參考了阮老師的文章.他的語言文字描述更準確透徹,且容易理解. 可以點選此處檢視.
官網有好幾種實現方式,都是開源貢獻者的精華,我只詳細看了php的實現,就已經深深佩服. 一個看似簡單的功能,竟然能實現的非常靈活, 僅需要很少的改動就能完整實現上述的4種認證授權模式,並且還有本文沒有提到,但是標準中定義的很多其他細節.

關於OAuth2.0的詳細介紹，請參考OAuth2.0協議標準。