Spring Security 實戰乾貨： 簡單的認識 OAuth2.0 協議
1.前言
歡迎閱讀 Spring Security 實戰乾貨 系列文章 。OAuth2.0 是近幾年比較流行的授權機制，對於普通使用者來說可能每天你都在用它，我們經常使用的第三方登入大都基於 OAuth2.0。隨著應用的互聯互通，個性化服務之間的相互呼叫，開放性的認證授權成為 客觀的需要。
2. OAuth2.0 的簡單認識
OAuth定義瞭如下角色，並明確區分了它們各自的關注點，以確保快速構建一致性的授權服務：
- Resource Owner 資源擁有者，通常指的是終端使用者，其作用是同意或者拒絕、甚至是選擇性的給第三方應用程式的授權請求。
- User Agent 使用者代理 指的的資源擁有者授權的一些渠道。一般指的是瀏覽器、APP
- Client 請求授權和請求訪問受限資源的客戶端程式。
- Authorization Server 對使用者授權進行鑑別並根據鑑別結果進行同意或拒絕的授權響應的伺服器。
- Resource Server 能夠接受和響應受保護資源請求的伺服器。
單純的文字性描述是不是有些難以理解。所以我這裡講一個親身經歷的事例來情景化以上的四個概念。馬上又到程式設計師集中面試的季節了，有一年我去面試，到了地方才發現如此的“高大上”，訪客需要通過驗證碼才能通過閘門，於是我聯絡了面試公司的HR ，後面的流程大概是這樣的:
- 我向面試公司（HR）傳送了一個進門的要求。
- HR 給了我一個可以獲取進門許可請求的連結。
- 我通過連結進行進門許可請求。
- 請求得到響應，返給我一個驗證碼。
- 我在閘門程式中輸入驗證碼。
- 驗證通過後放行。
在我學習了 OAuth2.0 協議之後我發現這次經歷可以體現出 OAuth2.0 的一些設計理念。訪客必須通過授權才能訪問大樓。這種方式避免了閒雜人等出入辦公場所，而且對訪客可控（從訪問時間和次數上），甚至可以實現對樓層的訪問可控（當然上面的例子中沒有）。
再結合 OAuth2.0 可以知道 訪客就是 Client，公司（業主）就是 Resource Owner，物業就是 Authorization Server ，那個閘機就是 Resource Server，閘機有可能也受到物業的管控。 這是那張著名的流程圖：
這個例子只是為了快速的來認識 OAuth2.0 ，它是一種有效的、可靠的委託授權框架。它提供了多種授權模式在不同的場景下供你選擇。
3. 授權模式
為了獲得訪問許可，客戶端需要向授權伺服器出示有效的授權憑證，也就是說客戶端必須得到使用者授權（authorization grant）OAuth2.0 提供了多種授權模式供開發者在不同的場景中使用，以下是授權模式的一些總結：
| 授權方式 | 客戶端型別/用例 |
|---|---|
| Authorization code | 旨在用於具有後端的傳統Web應用程式以及本機（移動或桌面）應用程式，以利用通過系統瀏覽器的單點登入功能。 |
| Implicit | 適用於不帶後端的基於瀏覽器的（JavaScript）應用程式。 |
| Password | 對於應用程式和授權伺服器屬於同一提供程式的受信任本機客戶端。 |
| Client credentials | 客戶端以自己的名義來獲取許可，而不是以終端使用者名稱義，或者可以說該使用者端也是資源擁有者 |
| Refresh token | 令牌失效後使客戶端可以重新整理其訪問令牌，而不必再次執行程式碼或 密碼授予的步驟。 |
| SAML 2.0 bearer | 使擁有SAML 2.0斷言（登入令牌）的客戶端將其交換為OAuth 2.0訪問令牌。 |
| JWT bearer | 擁有一個安全域中的JSON Web令牌斷言的客戶端將其交換為另一域中的OAuth 2.0訪問令牌。 |
| Device code | 裝置的唯一編碼，一般該編碼不可更改，多用於一些智慧裝置 |
| Token exchange | 使用代理模擬的方式獲取令牌 |
其中前五種為我們所熟知。我們後續會詳細介紹它們。
4. OAuth 2.0 的一些要點
摘自《OAuth 2 實戰》：
由於 OAuth2.0 被定義為一個框架，對於 OAuth2.0 是什麼和不是什麼，一直未明確。我們所說的 OAuth2.0 是指 OAuth2.0 核心規範中定義的協議，RFC 6749 核心規範詳述了一系列獲取訪問令牌的方法；還包括其伴隨規範中定義的 bearer 令牌，RFC 6750該規範規定了這種令牌的用法。獲取令牌和使用令牌這兩個環節是 OAuth2.0 的基本要素。正如我們將在本節中看到的，在更廣泛的 OAuth2.0 生態系統中存在很多其他技術，它們配合 OAuth2.0 核心，提供更多 OAuth2.0 本身不能提供的功能。我們認為，這樣的生態系統是協議健康發展的體現，但是不應與協議本身混為一談。
基於以上的原則 OAuth2.0 有以下一些要點需要明確被認識到：
- OAuth2.0 並非身份認證協議，雖然在授權的過程中涉及到身份認證，但是 OAuth2.0 協議本身並不處理使用者的資訊。客戶端訪問受保護的資源時並不關心資源的擁有者。
- OAuth2.0 不提供一些訊息簽名，為了保證安全性所以不應脫離 Https 。在使用其它協議或者系統時也應該明確一個安全機制來承擔 Https 所承擔的任務。
- OAuth2.0 並沒有定義加密方式，雖然目前使用的較多的是 JOSE 規範
- OAuth2.0 雖然令牌被客戶端持有並使用，但是客戶端並不能解析以及處理令牌。
5. 總結
OAuth2.0 其實還有個特點，它並不是單體協議。它被分成了多個定義和流程，每個定義和流程都有各自的應用場景。所以本文的目的在於場景化的引入 OAuth2.0，當你漸入佳境時，我們再來進行細節的探討吧。如果你想知道更多關於 OAuth2.0 協議的相關知識，可關注公眾號：Felordcn 回覆 oauth 獲取相關知識的資料