簡單認識 OAuth2.0 協議

1.前言

OAuth2.0 是近幾年比較流行的受權機制，對於普通用戶來講可能天天你都在用它，咱們常用的第三方登陸大都基於 OAuth2.0。
隨着應用的互聯互通，個性化服務之間的相互調用，開放性的受權成爲客觀的須要。

2. OAuth2.0 的簡單認識

OAuth 定義了以下角色，並明確區分了它們各自的關注點，以確保快速構建一致性的受權服務：

• Resource Owner 資源擁有者，一般指的是終端用戶，其做用是贊成或者拒絕、甚至是選擇性的給第三方應用程序的受權請求。
• User Agent 用戶代理 指的的資源擁有者受權的一些渠道。通常指的是瀏覽器、APP
• Client 請求受權和請求訪問受限資源的客戶端程序。
• Authorization Server 對用戶受權進行鑑別並根據鑑別結果進行贊成或拒絕的受權響應的服務器。
• Resource Server 可以接受和響應受保護資源請求的服務器。

單純的文字性描述是否是有些難以理解。

因此我這裏講一個親身經歷的事例來情景化以上的四個概念。

立刻又到程序員集中面試的季節了，有一年我去面試，到了地方纔發現如此的「高大上」，訪客須要經過驗證碼才能經過閘門，我聯繫了面試公司的 HR,HR 確認後微信發給我了一個連接，打開後是一個微信小程序給出瞭如下流程:

• 我向面試公司（HR）發送了一個進門的要求。
• HR 給了我一個能夠獲取進門許可請求的連接。
• 我經過連接進行進門許可請求。
• 請求獲得響應，返給我一個驗證碼。
• 我在閘門程序中輸入驗證碼。
• 驗證經過後放行。

在我學習了 OAuth2.0 協議以後我發現此次經歷能夠體現出 OAuth2.0 的一些設計理念。
訪客必須經過受權才能訪問大樓。

這種方式避免了閒雜人等出入辦公場所，並且對訪客可控（從訪問時間和次數上），甚至能夠實現對樓層的訪問可控（固然上面的例子中沒有）。

再結合 OAuth2.0 能夠知道 訪客就是 Client，公司（業主）就是 Resource Owner，物業就是 Authorization Server ，那個閘機就是 Resource Server，閘機有可能也受到物業的管控。

這是那張著名的流程圖：

這個例子只是爲了快速的來認識 OAuth2.0 ，它是一種有效的、可靠的委託受權框架。

它提供了多種受權模式在不一樣的場景下供你選擇。

3. 受權模式

爲了得到訪問許可，客戶端須要向受權服務器出示有效的受權憑證，也就是說客戶端必須獲得用戶受權（authorization grant）如下是受權方式的表格：

其中前五種爲咱們所熟知。咱們後續會詳細介紹它們。

4. OAuth 2.0 的一些要點

摘自《OAuth 2 實戰》：

因爲 OAuth2.0 被定義爲一個框架，對於 OAuth2.0 是什麼和不是什麼，一直未明確。咱們所說的 OAuth2.0 是指 OAuth2.0 核心規範中定義的協議，RFC 6749[1] 核心規範詳述了一系列獲取訪問令牌的方法；還包括其伴隨規範中定義的 bearer 令牌，RFC 6750[2]該規範規定了這種令牌的用法。獲取令牌和使用令牌這兩個環節是 OAuth2.0 的基本要素。正如咱們將在本節中看到的，在更普遍的 OAuth2.0 生態系統中存在不少其餘技術，它們配合 OAuth2.0 核心，提供更多 OAuth2.0 自己不能提供的功能。咱們認爲，這樣的生態系統是協議健康發展的體現，可是不該與協議自己混爲一談。

基於以上的原則 OAuth2.0 有如下一些要點須要明確被認識到：

•  OAuth2.0 並不是身份認證協議，雖然在受權的過程當中涉及到身份認證，可是 OAuth2.0 協議自己並不處理用戶的信息。客戶端訪問受保護的資源時並不關心資源的擁有者。
• OAuth2.0 不提供一些消息簽名，爲了保證安全性因此不該脫離 Https 。在使用其它協議或者系統時也應該明確一個安全機制來承擔 Https 所承擔的任務。
• OAuth2.0 並無定義加密方式，雖然目前使用的較多的是 JOSE 規範[3]
• OAuth2.0 雖然令牌被客戶端持有並使用，可是客戶端並不能解析以及處理令牌。
• 5. 總結

OAuth2.0 其實還有個特色，它並非單體協議。它被分紅了多個定義和流程，每一個定義和流程都有各自的應用場景。因此本文的目的在於場景化的引入 OAuth2.0，當你漸入佳境時，咱們再來進行細節的探討吧。