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 獲取相關知識的資料。