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 ，後面的流程大概是這樣的:

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

在我學習了 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 有如下一些要點須要明確被認識到：

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

5. 總結

OAuth2.0 其實還有個特色，它並非單體協議。它被分紅了多個定義和流程，每一個定義和流程都有各自的應用場景。因此本文的目的在於場景化的引入 OAuth2.0，當你漸入佳境時，咱們再來進行細節的探討吧。若是你想知道更多關於 OAuth2.0 協議的相關知識，可關注公衆號：Felordcn 回覆 oauth 獲取相關知識的資料。

關注公衆號：Felordcn 獲取更多資訊

我的博客：https://felord.cn