OAuth 2.0 是什么

OAuth 2.0 是一個授權協議，它允許軟件應用代表（而不是充當）資源擁有者去訪問資源擁有者的資源。應用向資源擁有者請求授權，然后取得令牌（token），并用它來訪問資源。這一切都不需要應用去充當資源擁有者的身份，因為令牌明確表示了被授予的訪問權。

作為一個授權框架，OAuth 關注的是如何讓一個系統組件獲取對另一個系統組件的訪問權限。在OAuth 的世界中，最常見的情形是客戶端應用代表資源擁有者（通常是最終用戶）訪問受保護資源。需要關心如下組件。

• 資源擁有者有權訪問API，并能將API 訪問權限委托出去。資源擁有者一般是能使用瀏覽器的人。
• 受保護資源是資源擁有者有權限訪問的組件。這樣的組件有多種形式，但大多數情況下是某種形式的Web API。
• 客戶端是代表資源擁有者訪問受保護資源的軟件。在OAuth 中，只要軟件使用了受保護資源上的API，它就是客戶端。

?客戶端需要資源擁有者暴露出憑據，例如LDAP身份驗證。

授權訪問

OAuth 協議的設計目的是：讓最終用戶通過OAuth 將他們在受保護資源上的部分權限委托給客戶端應用，使客戶端應用代表他們執行操作。為實現這一點，OAuth 在系統中引入了另外一個組件：授權服務器。

受保護資源依賴授權服務器向客戶端頒發專用的安全憑據——OAuth 訪問令牌。為了獲取令牌，客戶端首先將資源擁有者引導至授權服務器，請求資源擁有者為其授權。授權服務器先對資源擁有者進行身份認證，然后一般會讓資源擁有者選擇是否對客戶端授權。客戶端可以請求授權功能或權限范圍的子集，該子集可能會被資源擁有者進一步縮小。一旦授權請求被許可，客戶端就可以向授權服務器請求訪問令牌。按照資源擁有者的許可，客戶端可以使用該令牌對受保護資源上的API 進行訪問?。在這個過程中，沒有將資源擁有者的憑據暴露給客戶端：資源擁有者向授權服務器進行身份認證的過程中所用的信息是獨立于客戶端交互的。

OAuth授權過程??

?授權委托：重要性及應用

委托概念是OAuth 強大功能的根基。雖然OAuth 經常被稱作授權協議（這是RFC 中給出的名稱），但它也是一個委托協議。通常，被委托的是用戶權限的子集，但是OAuth 本身并不承載或者傳遞權限。相反，它提供了一種方法，讓客戶端可以請求用戶將部分權限委托給自己。然后，用戶可以批準這個委托請求。被批準之后，客戶端就可以去執行那些操作了。

委托協議和授權協議的區別是很重要的，因為OAuth 令牌中攜帶的授權信息對系統中的大部分組件是不透明的。只有受保護資源需要了解授權信息，只要它能從令牌中得知授權信息（既可以直接從令牌中獲取，也可以通過某種服務來獲取），它就可以按要求提供API 服務。

OAuth 2.0 不能做什么

• OAuth 沒有定義HTTP 協議之外的情形。由于使用bearer 令牌的OAuth 2.0 并不提供消息簽名，因此不應該脫離HTTPS（TLS 上的HTTP）使用。機密信息需要在網絡上傳播，所以OAuth需要TLS 這樣的傳輸機制來保護這些信息。
• OAuth 不是身份認證協議，盡管用戶確實存在，但OAuth 事務本身并不透露關于用戶的信息。
• OAuth 沒有定義用戶對用戶的授權機制，需要其他協議輔助，例如：User Managed Access 協議（將在第14 章中討論）就是為此而生，它規定了如何使用OAuth 構建一個支持用戶對用戶授權的系統。
• OAuth 沒有定義授權處理機制。
• OAuth 沒有定義令牌格式。實際上，OAuth 協議明確聲明了令牌的內容對客戶端是完全不透明的。
• OAuth 2.0 沒有定義加密方法。可以使用其他加密機制，例如：了JSON 對象簽名和加密（JOSE）規范套件。
• OAuth 2.0 不是單體協議。該規范被分成了多個定義和流程，每個定義和流程都有各自適用的場景。

OAuth 2.0 授權過程

OAuth 是一個復雜的安全協議，它需要不同的組件相互通信，OAuth 事務中的兩個重要步驟是頒發令牌和使用令牌。令牌表示授予客戶端的訪問權，它在OAuth 2.0 的各個部分都起到核心作用。盡管每個步驟的細節會因多種因素而異，但是一個規范的OAuth 事務包含以下事件。
(1) 資源擁有者向客戶端表示他希望客戶端代表他執行一些任務
(2) 客戶端在授權服務器上向資源擁有者請求授權。
(3) 資源擁有者許可客戶端的授權請求。
(4) 客戶端接收到來自授權服務器的令牌。
(5) 客戶端向受保護資源出示令牌。

OAuth 2.0 授權許可的完整過程

授權碼許可中用到了一個臨時憑據——授權碼——來表示資源擁有者同意向客戶端授權。

（0）資源擁有者訪問客戶端應用，并表明他希望客戶端代表自己去使用某一受保護資源。

（1）當客戶端發現需要獲取一個新的OAuth 訪問令牌時，它會將資源擁有者重定向（WEB一般指HTTP重定向）至授權服務器，并附帶一個授權請求，表示它要向資源擁有者請求一些權限?。

（2）重定向響應導致瀏覽器向授權服務器發送一個GET 請求，客戶端通過在發送給用戶的URL 中包含查詢參數，來標識自己的身份和要請求的授權詳情，如權限范圍等。雖然請求并不是由客戶端直接發出的，但授權服務器會解析這些參數并做出適當的反應。

（3）授權服務器會要求用戶進行身份認證。用戶身份認證直接在用戶（和用戶的瀏覽器）與授權服務器之間進行，這個過程對客戶端應
用不可見。

因為資源擁有者通過瀏覽器與授權端點交互，所以也要通過瀏覽器來完成身份認證。因此，有很多身份認證技術可以用于用戶身份認證流程。OAuth 沒有規定應該使用哪種身份認證技術，授權服務器可以自由選擇，例如用戶名/密碼、加密證書、安全令牌、聯合單點登錄或者其他方式。

（4）用戶向客戶端應用授權。在這一步，資源擁有者選擇將一部分權限授予客戶端應用，授權服務器提供了許多不同的選項來實現這一點

（5）授權服務器將用戶重定向回客戶端應用，一般通過redirect_uri實現，并且帶上授權碼。它是一次性的憑據，表示用戶授權決策的結果。客戶端會在接收到請求之后解析該參數以獲取授權碼，并在下一步使用該授權碼。

（6）現在客戶端已經得到授權碼，它可以將其發送給授權服務器的令牌端點。

（7）授權服務器接收該請求，如果請求有效，則頒發令牌。授權服務器需要執行多個步驟以確保請求是合法的。首先，它要驗證客戶端憑據（通過Authorization 頭部傳遞）以確定是哪個客戶端請求授權。然后，從請求主體中讀取code 參數的值，并從中獲取關于該授權碼的信息，包括發起初始授權請求的是哪個客戶端，執行授權的是哪個用戶，授權的內容是什么。如果授權碼有效且尚未使用過，而且發起該請求的客戶端與最初發起授權請求的客戶端相同，則授權服務器會生成一個新的訪問令牌并返回給客戶端。

（8）客戶端可以解析令牌響應并從中獲取令牌的值來訪問受保護資源。。令牌響應中還可以包含一個刷新令牌（用于獲取新的訪問令牌而不必重新請求授權），以及一些關于訪問令牌的附加信息，比如令牌的權限范圍和過期時間。客戶端可以將訪問令牌存儲在一個安全的地方，以便以后在用戶不在場時也能夠隨時使用。

bearer 令牌的使用權
OAuth 核心規范對bearer 令牌的使用做了規定，無論是誰，只要持有bearer 令牌就有權使用它。

客戶端出示令牌的方式有多種，備受推薦的方式：使用Authorization 頭部。

GET /resource HTTP/1.1
Host: localhost:9002
Accept: application/json
Connection: keep-alive
Authorization: Bearer 987tghjkiu6trfghjuytrghj

OAuth 中的角色：客戶端、授權服務器、資源擁有者、受保護資源

OAuth 系統中有4 個主要的角色：客戶端、授權服務器、資源擁有者以及受保護資源。這些組件分別負責OAuth 協議的不同部分，并且相互協作使OAuth 協議運轉。

?OAuth 客戶端是代表資源擁有者訪問受保護資源的軟件，它使用OAuth 來獲取訪問權限。它的職責主要是從授權服務器
獲取令牌以及在受保護資源上使用令牌。客戶端不需要理解令牌，也不需要查看令牌的內容。相反，客戶端只需要將令牌視為一個不透明的字符串即可。OAuth 客戶端可以是Web 應用、原生應用，甚至瀏覽器內的JavaScript 應用。

受保護資源能夠通過HTTP 服務器進行訪問，在訪問時需要OAuth 訪問令牌。受保護資源需要驗證收到的令牌，并決定是否響應以及如何響應請求。在OAuth 架構中，受保護資源對是否認可令牌擁有最終決定權。

資源擁有者是有權將訪問權限授權給客戶端的主體。與OAuth 系統中的其他組件不同，資源擁有者不是軟件。在大多數情況下，資源擁有者是一個人，他使用客戶端軟件訪問受他控制的資源。

OAuth 授權服務器是一個HTTP 服務器，它在OAuth 系統中充當中央組件。授權服務器對資源擁有者和客戶端進行身份認證，讓資源擁有者向客戶端授權、為客戶端頒發令牌。某些授權服務器還會提供額外的功能，例如令牌內省、記憶授權決策。

OAuth 的組件：令牌、權限范圍和授權許可

訪問令牌

OAuth 訪問令牌，有時也簡稱為令牌，由授權服務器頒發給客戶端，表示客戶端已被授予權限。OAuth 并沒有定義令牌本身的格式和內容，但它總是代表著：客戶端請求的訪問權限、對客戶端授權的資源擁有者，以及被授予的權限（通常包含一些受保護資源標識）。
OAuth 令牌對于客戶端來說是不透明的，也就是說客戶端不需要（通常也不能）查看令牌內容。客戶端要做的就是持有令牌，向授權服務器請求令牌，并向受保護資源出示令牌。OAuth 令牌并非對系統中的所有組件都不透明：授權服務器的任務是頒發令牌，受保護資源的任務則是驗證令牌。因此，它們都需要理解令牌本身，并知道其含義。然而，客戶端對這一切一無所知。這使得客戶端簡單得多，同時也使得授權服務器和受保護資源可以十分靈活地部署令牌。

權限范圍

OAuth的權限范圍表示一組訪問受保護資源的權限。OAuth協議中使用字符串表示權限范圍，可以用空格分隔的列表將它們合并為一個集合。因此，權限范圍的值不能包含空格。OAuth 并沒有規定權限范圍值的格式和結構。

刷新令牌

OAuth 刷新令牌在概念上與訪問令牌很相似，它也是由授權服務器頒發給客戶端的令牌，客戶端也不知道或不關心該令牌的內容。但不同的是，該令牌從來不會被發送給受保護資源。相反，客戶端使用刷新令牌向授權服務器請求新的訪問令牌，而不需要用戶參與。

?為什么客戶端需要刷新令牌？在OAuth 中，訪問令牌隨時可能失效。令牌有可能被用戶撤銷，也可能過期，或者其他系統導致令牌失效。訪問令牌失效后，客戶端在使用時會收到錯誤響應。OAuth 2.0 提供了讓令牌自動過期的選項，但是我們需要在用戶不在場的時候仍然能訪問資源。現在，刷新令牌取代了永不過期的訪問令牌，但它的作用不是訪問資源，而是獲取新的訪問令牌來訪問資源。這種做法以一種獨立但互補的方式，限制了刷新令牌和訪問令牌的暴露范圍。

刷新令牌還可以讓客戶端縮小它的權限范圍。如果客戶端被授予A、B、C 三個權限范圍，但是它知道某特定請求只需要A 權限范圍，則它可以使用刷新令牌重新獲取一個僅包含A 權限范圍的訪問令牌。這讓足夠智能的客戶端可以遵循最小權限安全原則。

授權許可

授權許可是OAuth 協議中的權限獲取方法，OAuth 客戶端用它來獲取受保護資源的訪問權限，成功之后客戶端會得到一個令牌。這可能是OAuth 2.0 中最令人困惑的術語之一，因為它既表示用戶授權所用的特定方式，也表示授權這個行為本身。前面詳細介紹過的授權碼許可類型加劇了這種困惑，因為開發人員有時候會看見傳回給客戶端的授權碼，并誤以為這個授權碼（僅授權碼）就是授權許可。雖然授權碼確實代表用戶的授權決策，但它不是授權許可本身。相反，整個OAuth 流程才是授權許可：客戶端將用戶重定向至授權端點，然后接收授權碼，最后用授權碼換取令牌。

換句話說，授權許可就是獲取令牌的方式。在本書中，就像在OAuth 社區中一樣，會偶爾將其稱為OAuth 協議的一個流程。OAuth 協議中有多種授權許可方法，并且各有特點。

OAuth 的角色與組件間的交互：后端信道、前端信道和端點

OAuth 是一個基于HTTP 的協議，但是與大多數基于HTTP 的協議不同，OAuth 中的交互并不總是通過簡單的HTTP 請求和響應來完成。

非HTTP 信道之上的OAuth
雖然OAuth 是基于HTTP 的協議，但已有很多規范定義了如何將OAuth 流程中的不同部分遷移到非HTTP 協議上。例如，已經有標準草案提出了如何在通用安全服務應用程序接口（GSS-API）和受限應用程序協議（CoAP）上使用OAuth 令牌。在這些草案中，仍然可以使用HTTP 來啟動OAuth 流程，但它們是想將基于HTTP 的OAuth 組件直接搬到其他協議上去。

后端信道通信

OAuth 流程中的很多部分都使用標準的HTTP 請求和響應格式來相互通信。由于這些請求通常都發生在資源擁有者和用戶代理的可見范圍之外，因此它們統稱為后端信道通信。
這些請求和響應使用了所有常規的HTTP 機制來通信：頭部、查詢參數、HTTP 方法和HTTP主體都能承載對OAuth 事務至關重要的信息。請注意，由于多數簡單的Web API 只需要客戶端開發人員關注響應主體，這可能包含了你不熟悉的一些HTTP 機制。
授權服務器提供了一個授權端點，供客戶端請求訪問令牌和刷新令牌。客戶端直接向該端點發出請求，攜帶一組表單格式的參數，授權服務器解析并處理這些參數。然后授權服務器返回一個代表令牌的JSON 對象。

前端信道通信

在標準的HTTP 通信中，HTTP 客戶端向服務器直接發送一個請求，其中包含頭部、查詢參數、主體及其他信息。然后HTTP 服務器可以查看這些信息，并決定如何響應請求，響應中包含頭部、主體及其他信息。然而，在OAuth 中，在某些情況下兩個組件是無法直接相互發送請求和響應的，例如客戶端與授權服務器的授權端點交互的時候。前端信道通信就是一種間接通信方法，它將Web 瀏覽器作為媒介，使用HTTP 請求實現兩個系統間的間接通信。

這一技術隔離了瀏覽器兩端的會話，實現了跨安全域工作。例如，如果用戶需要向其中一個組件進行身份認證，并不需要將憑據暴露給另一個系統。這樣，在保持信息隔離的情況下，仍然能讓用戶在通信中發揮作用。

兩個不直接交互的軟件是如何實現通信的呢？前端信道通信是這樣實現的：發起方在一個URL 中附加參數并指示瀏覽器跳轉至該URL。然后接收方可以解析該入站URL（由瀏覽器跳轉來的），并使用其中包含的信息。之后，接收方可以將瀏覽器重定向至發起方托管的URL，并使用同樣的方式在URL 中附加參數。這樣，兩個軟件就以Web 瀏覽器為媒介，實現了間接通信。這意味著每個前端信道的請求和響應實際上是一對HTTP 請求/響應事務。

?在前面看到的授權碼許可中，客戶端需要將用戶重定向至授權端點，但是也需要將其請求的內容信息傳遞給授權服務器。為此，客戶端向瀏覽器發送一個HTTP 重定向。這個重定向的目標是授權服務器的URL，并且其查詢參數中附有特定參數。

HTTP 302 Found
Location: http://localhost:9001/authorize?client_id=oauth-client-1&response_type=code&state=843hi43824h42tj

?授權服務器可以像處理一般的HTTP 請求一樣解析傳入的URL，從參數中獲取信息。在這個環節，授權服務器可以與資源擁有者進行交互，通過瀏覽器執行一系列HTTP 事務，對資源擁有者進行身份認證并請求其授權。當需要給客戶端返回授權碼時，授權服務器也向瀏覽器返回重定向響應，但是這一次的重定向目標是客戶端的redirect_uri。授權服務器也會在重定向的查詢參數中附帶信息。

HTTP 302 Found
Location: http://localhost:9000/oauth_callback?code=23ASKBWe4&state=843hi43824h42tj

?所有通過前端信道傳遞的信息都可供瀏覽器訪問，既能被讀取，也可能在最終請求發出之前被篡改。OAuth 協議已經考慮到這一點，它限制了能通過前端信道傳輸的信息類別，并確保只要是通過前端信道傳輸的信息，就不能在授權任務中單獨使用。授權碼不能被瀏覽器直接使用，相反它必須通過后端信道與客戶端憑據一起出示。在有些協議中，比如OpenID Connect，要求客戶端或者授權服務器對前端信道中傳輸的消息簽名，通過這樣的安全機制增加一層保護。

?

總結

以上是生活随笔為你收集整理的OAuth2（一）——核心概念的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。