OAuth 2 0 授權方式講解，規範實踐和應用

網上看了一些oauth 2.0的授權方法，儘管講解的沒有什麼邏輯性錯誤，但是存在乙個問題，那就是單純的講解協議規範卻脫離了實際的應用，缺少乾貨，所以才有了這篇文章，內容基於實際業務進行講解，力求基於實踐說規範

oauth 引入了乙個授權層，用來分離兩種不同的角色：客戶端和資源所有者。......資源所有者同意以後，資源伺服器可以向客戶端頒發令牌。客戶端通過令牌，去請求資料。

oauth 2.0規定了四種獲得令牌的流程。你可以選擇最適合自己的那一種，向第三方應用頒發令牌。下面就是這四種授權方式。

授權碼（authorization-code）

隱藏式（

implicit

）密碼式（password）

客戶端憑證（client credentials）

下面針對每一種進行詳細的解讀

當使用者點選授權後，平台會**a**在註冊應用時提供的**位址（有些平台需要申請授權時實時的提供），並攜帶code碼（如有必要需要同時攜帶其他引數比如state引數），a**拿到code碼後通過平台提供的sdk獲取openid、token、expired、refresh_oken、refesh_time等資訊（code為引數呼叫開放平台介面獲取引數）

使用者拿到openid和token（令牌）就可以呼叫開放平台提供的服務了,到此，乙個標準的授權碼授權流程就結束了。需要知道的是token是有有效期的，適用方需要指定token重新整理策略,通過refresh_oken呼叫重新整理介面獲取最新的token；

思考：為什麼開放平台**的時候是返回code，而不是直接返回token、openid等資訊

隱藏式（implicit）

有些 web 應用是純前端應用，沒有後端。這時就不能用上面的方式了，必須將令牌儲存在前端。rfc 6749 就規定了第二種方式，允許直接向前端頒發令牌。這種方式沒有授權碼這個中間步驟，所以稱為（授權碼）"隱藏式"（implicit）。

隱藏式授權的流程相對簡單，但安全性不高，所以只能用於以下安全性要求不高的場景，其基本步驟如下：

第一步，a **提供乙個鏈結，要求使用者跳轉到 b **，授權使用者資料給 a **使用，如下：

上面的url中res_type=token，標示返回的引數為token，也可以用其他的約定形式例如（authtype=implicit）

第二步，使用者跳轉到 b **，登入後同意給予 a **授權。這時，b **就會跳回redirect_uri引數指定的跳轉**，並且把令牌作為 url 引數，傳給 a **。

access_token

注意，令牌的位置是 url 錨點（fragment），而不是查詢引數，這是因為 oauth 2.0 允許跳轉**是 http 協議，因此存在"中間人攻擊"的風險，而瀏覽器跳轉時，錨點不會發到伺服器，就減少了洩漏令牌的風險。

關於token有效期的問題，一般採用隱藏式授權的的引用的有效期一般定為會話期間，隨著瀏覽器關閉，令牌隨之失效。一般不涉及到令牌的重新整理問題（授權碼授權需要定期的更新令牌）

密碼式（password）如果你高度信任某個應用，rfc 6749 也允許使用者把使用者名稱和密碼，直接告訴該應用。該應用就使用你的密碼，申請令牌，這種方式稱為"密碼式"（password）

客戶端憑證（clientcredentials）

oauth2.0僅僅是個協議或者說是個規範，本身沒有什麼意義，它的意義在於為嘗試為某種授權場景提供思路和規範，在設計自己的授權協議或者對接某開放平台的時候，能夠思路清理的理解每乙個步驟，並且做出正確的選擇，顯示時間中授權碼的形式經常遇到，另外三種暫未遇到過，一般都是帶有加密演算法的變形應用（介面鑑權），小夥伴們要靈活掌握；在後面的文章中我會詳細講解介面鑑權的集中形式。

OAuth 2 0 授權方式講解，規範實踐和應用

Oauth2 0授權方式

OAuth2 0 授權碼方式

OAuth2 0認證授權

OAuth 2 0 授權方式講解，規範實踐和應用

Oauth2 0授權方式

OAuth2 0 授權碼方式

OAuth2 0認證授權

相關推薦