4-OAuth2.0協(xié)議簡單認(rèn)識

上一篇胖哥和大家一起通過日志分析了Spring Security OAuth2的authorization_code模式，相信流程你已經(jīng)了解了一些。但是你會不會有這樣的疑問，用戶訪問客戶端自己的資源/foo/hello為啥還要跳到第三方gitee登錄？正常情況下自己的資源只要自己認(rèn)證就能訪問，借助于其它平臺認(rèn)證授權(quán)是怎么回事？

解惑

Spring Security OAuth2 Login純粹是“借別人的雞下自己的蛋”。真正的目的是授權(quán)去訪問/v5/user獲得gitee平臺當(dāng)前用戶的信息，借第三方平臺的用戶注冊信息來給客戶端平臺做自己的認(rèn)證，我們無條件地信任了gitee用戶。 如果第三方平臺不開放user-info-uri 獲取用戶注冊信息的話，OAuth2 Login就做不成。

我個人認(rèn)為Spring Security的OAuth2 Login是在OAuth2授權(quán)的基礎(chǔ)上自行實(shí)現(xiàn)的認(rèn)證。

/foo/hello的訪問控制還是Spring Security自有的機(jī)制，和OAuth2無關(guān)。

OAuth2 的簡單認(rèn)識

OAuth2定義了如下角色，并明確區(qū)分了它們各自的關(guān)注點(diǎn)，以確保快速構(gòu)建一致性的授權(quán)服務(wù)：

Resource Owner 資源擁有者，通常指的是終端用戶，其作用是同意或者拒絕、甚至是選擇性的給第三方應(yīng)用程序的授權(quán)請求。

User Agent 用戶代理，發(fā)起請求的客戶端。一般指的是瀏覽器、APP。

Client 請求授權(quán)和請求訪問受限資源的客戶端程序。

Authorization Server 對用戶授權(quán)進(jìn)行鑒別并根據(jù)鑒別結(jié)果進(jìn)行同意或拒絕的授權(quán)響應(yīng)的服務(wù)器。

Resource Server 能夠接受和響應(yīng)受保護(hù)資源請求的服務(wù)器。

這是那張著名的流程圖：

這個例子只是為了快速的來認(rèn)識 OAuth2.0 ，它是一種有效的、可靠的委托授權(quán)框架。它提供了多種授權(quán)模式在不同的場景下供你選擇。

授權(quán)模式

為了獲得訪問許可，客戶端需要向授權(quán)服務(wù)器出示有效的授權(quán)憑證，也就是說客戶端必須得到用戶授權(quán)（authorization grant）OAuth2 提供了多種授權(quán)模式供開發(fā)者在不同的場景中使用，以下是授權(quán)模式的一些總結(jié)：

其中前五種為我們所熟知。

OAuth2的使用場景

OAuth2都用于哪些場景呢？這里我大致羅列了一下，主要有以下幾個場景：

千萬不要搞錯了使用場景，把簡單的問題復(fù)雜化。

OAuth2 的一些要點(diǎn)

摘自《OAuth 2 實(shí)戰(zhàn)》：

由于 OAuth2.0 被定義為一個框架，對于 OAuth2.0 是什么和不是什么，一直未明確。我們所說的 OAuth2.0 是指 OAuth2.0 核心規(guī)范中定義的協(xié)議，RFC 6749 核心規(guī)范詳述了一系列獲取訪問令牌的方法；還包括其伴隨規(guī)范中定義的 bearer 令牌，RFC 6750該規(guī)范規(guī)定了這種令牌的用法。獲取令牌和使用令牌這兩個環(huán)節(jié)是 OAuth2.0 的基本要素。正如我們將在本節(jié)中看到的，在更廣泛的 OAuth2.0 生態(tài)系統(tǒng)中存在很多其他技術(shù)，它們配合 OAuth2.0 核心，提供更多 OAuth2.0 本身不能提供的功能。我們認(rèn)為，這樣的生態(tài)系統(tǒng)是協(xié)議健康發(fā)展的體現(xiàn)，但是不應(yīng)與協(xié)議本身混為一談。

基于以上的原則 OAuth2 有以下一些要點(diǎn)需要明確被認(rèn)識到：

OAuth2 并非身份認(rèn)證協(xié)議，雖然在授權(quán)的過程中涉及到身份認(rèn)證，但是 OAuth2協(xié)議本身并不處理用戶的信息。客戶端訪問受保護(hù)的資源時并不關(guān)心資源的擁有者。

OAuth2不提供一些消息簽名，為了保證安全性所以不應(yīng)脫離 Https 。在使用其它協(xié)議或者系統(tǒng)時也應(yīng)該明確一個安全機(jī)制來承擔(dān) Https 所承擔(dān)的任務(wù)。

OAuth2并沒有定義加密方式，雖然目前使用的較多的是 JOSE 規(guī)范

OAuth2雖然令牌被客戶端持有并使用，但是客戶端并不能解析以及處理令牌。

OAuth2應(yīng)該建立在HTTPS協(xié)議之上。

OAuth2的幾個誤區(qū)

OAuth2客戶端無法認(rèn)定資源擁有者就是正確的擁有者，它沒有鑒別能力，雖然市面上的OAuth2能夠保證授權(quán)的安全性，但是OAuth2本身并沒有對用戶認(rèn)證提供明確的規(guī)范，OAuth2協(xié)議僅僅是授權(quán)協(xié)議。

OAuth2和JWT沒有必然關(guān)系，OAuth2只要不使用JWT bearer模式，就可以不使用JWT。

OAuth2現(xiàn)在不僅僅指的是OAuth2.0，還有可能是最新的OAuth2.1。

OIDC

OIDC是OAuth2的一個內(nèi)建協(xié)議，是對OAuth2的一個補(bǔ)充，它支持對資源擁有者的認(rèn)證。

OIDC規(guī)定了一些術(shù)語用來提高我們學(xué)習(xí)的門檻:

EU：End User 終端用戶

RP：Relying Party 即客戶端（client），授權(quán)和認(rèn)證的最終消費(fèi)方，我搞不懂為啥要玩多余的概念

OP：OpenID Provider，對EU進(jìn)行認(rèn)證的服務(wù)提供者

ID Token：JWT格式，EU的認(rèn)證通過后生成憑證，供RP消費(fèi)

UserInfo Endpoint： 通過憑據(jù)查詢用戶基本信息的接口，建議上HTTPS。

和OAuth2不同，OIDC是需要JWT來支持的。

OIDC復(fù)用了OAuth2的授權(quán)流程，在授權(quán)的過程中增加了一些“小動作”來進(jìn)行用戶認(rèn)證。結(jié)合其術(shù)語，大致的流程是這樣的：

RP發(fā)送一個認(rèn)證請求給OP；

OP先對EU進(jìn)行身份認(rèn)證，確認(rèn)無誤后提供授權(quán)；

OP把ID Token和Access Token（需要的話）返回給RP；

RP使用Access Token發(fā)送一個請求UserInfo EndPoint；（可選）

UserInfo EndPoint返回EU的Claims。（基于第4個步驟可選）

看不懂流程沒有關(guān)系，知道OIDC比OAuth2多一個功能，可以做用戶認(rèn)證就行了。

小結(jié)

OAuth2 其實(shí)還有個特點(diǎn)，它并不是單體協(xié)議。它被分成了多個定義和流程，每個定義和流程都有各自的應(yīng)用場景，因此它非常龐大，一不小心就容易陷入迷宮。以下來自It’s time for OAuth2.1的OAuth2迷宮圖。

這個章節(jié)可以幫助你去了解OAuth2協(xié)議。關(guān)于細(xì)節(jié)部分需要根據(jù)場景去講，涉及的東西相當(dāng)?shù)亩啵釸FC文檔都要幾十個。 協(xié)議這個東西學(xué)起來確實(shí)比較枯燥難懂，需要結(jié)合一些場景才能說清楚，不過這個是無法跳過去的東西。先不要想太多為什么，能看懂多少看懂多少，等找到場景用起來了就明白了。

在專欄后面的文章中，我會根據(jù)場景穿插介紹OAuth2.0。如果遇到疑難雜癥，請聯(lián)系我。

Access TCP/IP

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。