oauth2.0是一套標準.
第三方應用–比如乙個繪圖的小軟體」paint」
使用者–比如」我的qq空間賬號ws」
私密資訊–比如我qq空間中的**
資源服務方-qq空間
認證伺服器-qq空間
正常情況下,要訪問使用者ws的qq中的**, 需要將賬號和密碼傳送到qq空間的認證伺服器驗證身份.
但是第三方應用要訪問, 怎麼辦呢?
把賬號密碼告訴第三方應用paint,肯定不行
這就相當於把密碼告訴別人,而且還是我不認識的人.不安全.
paint只需要乙個**,但把密碼都給他了,他連我的日記都能看了.
paint如果把密碼公開或者洩露給別人的,那我怎麼辦.
這是最簡單的一種方式, 不需要得到使用者ws授權,只要資源服務方qq空間對第三方應用paint發放乙個client_id和client_secret, 第三方應用訪問資源時通過剛才的id和secret進行驗證後即返回access_token.
當然,這樣對使用者ws有些不公平,但實際上,在第三方應用paint所訪問的資源與使用者ws關係不大時就比較方便了.
此時,paint能從qq空間獲取任意,只需要向qq空間認證,因為這些與具體某個使用者無關.
使用者ws將自己的使用者名稱密碼直接告知第三方應用paint, paint即可使用這個密碼向資源服務方qq空間獲取.
這個方法就是剛才說過的很不安全的方法.但仍然有其適用的範圍.
就是在使用者ws與第三方應用paint更相熟情況, 也就是ws完全信任paint,放心的把密碼交給paint使用.
此時,paint僅能獲取使用者ws的, 不能獲取ws2,ws3等使用者的,所以paint一定要取得ws的信任拿到密碼.
paint要得到access_token並且,不必知道ws的具體密碼.
paint會訪問qq空間某一api介面時,告知client_id, user_id, redirect_url,qq空間收到請求後將頁面跳轉到認證頁面,
然後瀏覽器跳轉至qq空間的認證頁面,使用者ws在此頁面輸入使用者名稱密碼,在qq空間認證成功後.
qq空間將瀏覽器跳轉到paint提前指定的redirect_url上,傳入access_token. 這時paint即可得到access_token.
注:在一些移動應用的程式內部實現時,即使redirect_url是乙個錯誤的位址,也能解析到access_token.這裡的access_token如何能被paint得到? 就是解析redirect_url的引數.
比如這樣 ,直接取url引數得到access_token為abcdefg.
因為應用內部會收到302跳轉的資料,只要從中解析到token後,不執行跳轉動作即可.
這個問題,困惑了我好久.經過朋友幫助才終於理解.
授權碼模式與簡化模式的過程是一樣的.
不同之處在於,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的.相對來說更安全.
上面就是自己的淺見,本人實踐過程僅搭建了乙個簡單的oauth2.0伺服器,用於其他合作夥伴訪問我們的api時進行許可權認證.
是乙個比較簡單的應用.
在學習理解oauth2.0過程,參考了阮老師的文章.他的語言文字描述更準確透徹,且容易理解. 可以點選此處檢視.
另外,oauth2.0官網上的教程一步一步搭建oauth2.0伺服器對我幫助也很大.
官網有好幾種實現方式,都是開源貢獻者的精華,我只詳細看了php的實現,就已經深深佩服.
乙個看似簡單的功能,竟然能實現的非常靈活, 僅需要很少的改動就能完整實現上述的4種認證授權模式,並且還有本文沒有提到,但是標準中定義的很多其他細節.
張天琪——oauth security.pdf
人人網
來往 oauth協議例項化描述
下面我以例項化方式來幫助讀者理解授權碼型別的授權協議的執行過程。假設:
(1) alice有乙個有效的google帳號；
(2) facebook.com已經在google authorization server上註冊了client身份，已經獲得(client_id, client_secret)，注意client_secret是client與as之間的乙個共享金鑰。
(3) alice想授權facebook.com檢視她的聯絡人列表(
圖3展示了alice、facebook.com、google資源伺服器、以及google oauth授權伺服器之間的協議執行過程。
Oauth2 0授權方式
oauth2.0是一套標準。這個標準解決了這樣的乙個問題。給第三方應用乙個臨時密碼,過期作廢,而且這個密碼的訪問許可權可由我隨時取消。這樣就足夠安全了。這個臨時密碼就是access token。發放access token的方法就多種多樣了,這些方法叫做授權模式。oauth2為我們提供了四種授權方式...
OAuth2 0認證授權
授權碼模式 authorization code 是功能最完整 流程最嚴密的授權模式。它的特點就是通過客戶端的後台伺服器，與 服務提供商 的認證伺服器進行互動。client id x client secret x response type 表示授權型別，必選項，此處的值固定為 code clie...
OAuth 2 0授權框架
背景介紹 oauth2.0授權框架支援第三方應用程式以獲取對http服務的有限訪問權，通過協調批准互動來代表資源所有者，在資源所有者和http服務之間，或者通過允許第三方應用程式代表自己獲取訪問許可權。這個規範取代並淘汰了所描述的oauth1.0協議 一 傳統模式的身份驗證模型 在傳統的客戶端 伺服...