授權(quán)和認(rèn)證是每個(gè)項(xiàng)目中不可或缺的一部分，脆弱的授權(quán)、認(rèn)證流程會(huì)在惡意攻擊中不堪一擊，會(huì)在項(xiàng)目運(yùn)行過(guò)程中無(wú)法承受高流量的沖擊。在這個(gè)環(huán)節(jié)中，OAuth 認(rèn)證、SSO 單點(diǎn)登錄、CAS 中央認(rèn)證服務(wù)會(huì)頻繁地出現(xiàn)在相關(guān)業(yè)務(wù)的開發(fā)人員視野中，可是總是多多少少的懵懵懂懂。

這里筆者會(huì)盡力從源頭上解決對(duì)于相關(guān)概念的理解，以及在項(xiàng)目中的實(shí)踐。并且收錄部分面試過(guò)程中會(huì)遇到的問題。

旨在解決相關(guān)人員對(duì)于概念的深入理解，對(duì)于項(xiàng)目的實(shí)踐認(rèn)識(shí)，對(duì)于面試的關(guān)鍵點(diǎn)剖析。單個(gè)篇幅無(wú)法做到面面俱到，盡力估計(jì)，過(guò)程中會(huì)提供 JAVA、C Sharp 的代碼解釋。

在本場(chǎng) Chat 中，會(huì)講到如下內(nèi)容：

OAuth 的說(shuō)明、應(yīng)用
SSO 單點(diǎn)登錄的說(shuō)明、應(yīng)用
CAS 的說(shuō)明應(yīng)用
JWT 和授權(quán)的關(guān)系
C# 中間件 OWIN
常見授權(quán)認(rèn)證相關(guān)的面試題收集、剖析

OAuth 的說(shuō)明、應(yīng)用

OAuth 是什么

在維基百科中對(duì)于 OAuth 的解釋如下：

開放授權(quán)（OAuth）是一個(gè)開放標(biāo)準(zhǔn)，允許用戶讓第三方應(yīng)用訪問該用戶在某一網(wǎng)站上存儲(chǔ)的私密的資源（如照片、視頻、聯(lián)系人列表），而無(wú)需將用戶名和密碼提供給第三方應(yīng)用。

OAuth 允許用戶提供一個(gè)令牌，而不是用戶名和密碼來(lái)訪問他們存放在特定服務(wù)提供者的數(shù)據(jù)。每一個(gè)令牌授權(quán)一個(gè)特定的網(wǎng)站（例如，視頻編輯網(wǎng)站）在特定的時(shí)段（例如，接下來(lái)的 2 小時(shí)內(nèi)）內(nèi)訪問特定的資源（例如僅僅是某一相冊(cè)中的視頻）。這樣，OAuth 讓用戶可以授權(quán)第三方網(wǎng)站訪問他們存儲(chǔ)在另外服務(wù)提供者的某些特定信息，而非所有內(nèi)容。

OAuth 是 OpenID 的一個(gè)補(bǔ)充，但是完全不同的服務(wù)。

在百度百科中對(duì)于 OAuth 的解釋如下：

OAuth 協(xié)議為用戶資源的授權(quán)提供了一個(gè)安全的、開放而又簡(jiǎn)易的標(biāo)準(zhǔn)。與以往的授權(quán)方式不同之處是 OAuth 的授權(quán)不會(huì)使第三方觸及到用戶的帳號(hào)信息（如用戶名與密碼），即第三方無(wú)需使用用戶的用戶名與密碼就可以申請(qǐng)獲得該用戶資源的授權(quán)，因此 OAuth 是安全的。OAuth 是 Open Authorization 的簡(jiǎn)寫。

在 OAuth 2.0 的官方網(wǎng)站中的解釋如下（摘自：https://oauth.net/）：

An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop Applications.

在 IETF 組織中的對(duì)于 OAuth 2.0 Authorization Framework 對(duì)應(yīng)的摘要描述如下：

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.

通過(guò)這幾個(gè)方面的查看，可以明確的消除對(duì)于 OAuth 的錯(cuò)誤認(rèn)識(shí)，OAuth 不是一個(gè)技術(shù)框架，也不是一個(gè) jar 包，也不是一個(gè) dll 程序集，它僅僅是一個(gè) protocol，被翻譯為協(xié)議、標(biāo)準(zhǔn)、或者規(guī)則。這只是對(duì)于 OAuth 的一個(gè)宏觀認(rèn)識(shí)。

在 oauth.net 中的簡(jiǎn)介可以了解到，OAuth 2.0 是允許通過(guò)使用簡(jiǎn)單標(biāo)準(zhǔn)的方法從 Web、移動(dòng)和桌面應(yīng)用程序中進(jìn)行安全授權(quán)的開放協(xié)議。

OAuth 的歷史版本中有 OAuth 1.0 和 OAuth 2.0，其中 OAuth 1.0 在 2010 年發(fā)表為 RFC5849，OAuth 2.0 為 RFC6749，并且 OAuth 2.0 不向下兼容 OAuth 1.0，目前 OAuth 2.0 被廣泛使用，因此這里不再對(duì) OAuth 1.0 進(jìn)行更多的描述。

上面是對(duì) OAuth 以及 OAuth 2.0 的宏觀認(rèn)識(shí)，下面對(duì)于 OAuth 2.0 包括的幾種方式進(jìn)行介紹。

認(rèn)證和授權(quán)中不得不提及的 OAuth、SSO、CAS、JWT

（圖片來(lái)自 tools.ietf.org 的截圖）

如圖所示，在 RFC6749 可以得到最官方的幾種授權(quán)類型：

Authorization Code Grant，授權(quán)碼授予類型
Implicit Grant，隱私授予類型
Resource Owner Password Credentials Grant，用戶密碼憑證授予類型
Client Credentials Grant，客戶端授予類型
Extension Grant，其他可以根據(jù)具體情況進(jìn)行擴(kuò)展的類型

這也是 OAuth 2.0 區(qū)別于 OAuth 1.0 的地方，OAuth 2.0 中工作組所作出的明確決定是，它不再是一個(gè)單個(gè)協(xié)議，而是一個(gè)框架。從名字上也可以看出來(lái)，1.0 是 protocol，而 2.0 的標(biāo)題是 framework。

授權(quán)碼授予類型

授權(quán)碼類型是目前 OAuth 2.0 中最常用，最安全的一種類型。通過(guò)去授權(quán)端獲取授權(quán)碼，利用授權(quán)碼換取 token，通過(guò)使用 token 去資源服務(wù)器獲取受保護(hù)資源。

以阿里云的內(nèi)容協(xié)作平臺(tái) CCP 的官方文檔為實(shí)例：

（圖片引用 help.aliyun.com/）

隱式授權(quán)類型

Implicit Grant 有的地方被翻譯成簡(jiǎn)單授權(quán)，但是筆者認(rèn)為翻譯成簡(jiǎn)單授權(quán)有點(diǎn)偏離原有的意思。它只是針對(duì)授權(quán)碼的環(huán)節(jié)做了一定簡(jiǎn)化，但是它的使用并不能被視為簡(jiǎn)單的授權(quán)類型。

授權(quán)碼流程的不同步驟的關(guān)鍵之處，在于能夠保持不同組件之間的分離，瀏覽器不知道客戶端應(yīng)該知道的內(nèi)容，客戶端無(wú)法獲取到瀏覽器的狀態(tài)。但是，如果把客戶端放到瀏覽器中，該怎么辦呢？這種情況在目前的 SPA 單頁(yè)面應(yīng)用程序中經(jīng)常會(huì)出現(xiàn)。客戶端執(zhí)行的所有過(guò)程，由于都是基于瀏覽器實(shí)現(xiàn)的，所以幾乎相當(dāng)于在瀏覽器上裸奔。

（圖片引用 OAuth 2.0 in Action）

使用這種方法，沒有現(xiàn)實(shí)的方法來(lái)保護(hù)客戶端的密碼信息，因?yàn)樗枰獙?duì)于瀏覽器可用才能執(zhí)行后續(xù)流程。

隱式授予流程不能用于獲取刷新令牌，由于基于瀏覽器的應(yīng)用基本上都是短時(shí)的連接，僅持續(xù)加載它們的瀏覽器的上下文的會(huì)話長(zhǎng)度，因此，刷新令牌的用途非常有限。

與其他授予類型不同，可以假定資源所有者仍處于瀏覽器中，并在必要的時(shí)候可用于重新授權(quán)客戶端。授權(quán)服務(wù)器仍能夠應(yīng)用首次使用信任（TOFU）原則從而使重新認(rèn)證成為無(wú)縫的用戶體驗(yàn)。

以阿里云的內(nèi)容協(xié)作平臺(tái) CCP 的官方文檔為實(shí)例：

（圖片引用 help.aliyun.com）

客戶端憑證授權(quán)類型

（圖片引用 OAuth 2.0 in Action）

在 RFC 中是這么進(jìn)行描述的：

（圖片引用：tools.ietf.org）

實(shí)際上是一個(gè)道理，只是表現(xiàn)形式稍微有一點(diǎn)不同而已。客戶端直接對(duì)它自己進(jìn)行驗(yàn)證，然后授權(quán)服務(wù)器頒發(fā)適當(dāng)?shù)牧钆啤?/p>

資源所有者授予類型

（圖片引用 OAuth 2.0 in Action）

通過(guò)使用 Resource Owner 的用戶名和密碼來(lái)?yè)Q取令牌，這種方式一般是不提倡使用的，原因是當(dāng)用戶名和密碼暴露出來(lái)的時(shí)候，就自然會(huì)導(dǎo)致攻擊面變得更大，風(fēng)險(xiǎn)更高。

在上述幾種 Grant Type 中的 Client，它并不能被簡(jiǎn)單的理解為瀏覽器或者桌面應(yīng)用，在 OAuth 中，只要軟件使用受保護(hù)資源上的 API，那么它就被視為客戶端。

以上就是對(duì)于 OAuth 的說(shuō)明，以及 OAuth 2.0 framework 中涉及到的幾種類型的圖示和描述，以及在實(shí)際場(chǎng)景中的應(yīng)用流程。

對(duì)于代碼 OAuth 2.0 的具體實(shí)現(xiàn)過(guò)程，由于每一個(gè)環(huán)節(jié)都涉及很多內(nèi)容，不在編碼過(guò)程中消化就會(huì)很難理解，后續(xù)將會(huì)在專欄中進(jìn)行詳細(xì)過(guò)程的剖析。這里通過(guò)概念的引入和宏觀的理解，消除平時(shí)工作過(guò)程中對(duì)于概念的錯(cuò)誤認(rèn)識(shí)。

SSO 的說(shuō)明和應(yīng)用

SSO，single sign on 單點(diǎn)登錄，單點(diǎn)登錄為用戶提供無(wú)縫的身份驗(yàn)證體驗(yàn)。在構(gòu)建的應(yīng)用程序中，一旦登錄這些應(yīng)用程序中的一個(gè)，當(dāng)使用其他應(yīng)用程序的情況下，不需要再次登錄。反之，在登出的過(guò)程中，只要一個(gè)應(yīng)用程序登出，那么所有應(yīng)用對(duì)應(yīng)的登錄狀態(tài)全是登出。

這就是 SSO，單點(diǎn)登錄的基本含義。

CAS

CAS，Central Authentication Service，集中式身份驗(yàn)證。SSO 和 CAS 是密不可分的，SSO 可以理解為一個(gè)軟件系統(tǒng)，而 CAS 是作為實(shí)現(xiàn) SSO 的一種解決方案。更準(zhǔn)確的來(lái)說(shuō)，它是一個(gè)規(guī)范性質(zhì)的協(xié)議。

（圖片引自 apereo.github.io 截圖）

對(duì)應(yīng)的 C sharp 的源碼可以參考如下的 GitHub 源碼，地址為：

https://github.com/apereo/dotnet-cas-client

對(duì)應(yīng) Java 的源碼可以參考如下 GitHub 的源碼，地址為：

https://github.com/apereo/cas

JWT 和授權(quán)的關(guān)系

首先要知道的可能是 JWT 是什么？這個(gè)概念在很多地方，要么是沒有被解釋，要么是被結(jié)合場(chǎng)景使用的解釋，偏離了它本身的概念。那么參考 IETF 的說(shuō)明來(lái)對(duì) JWT 的本質(zhì)進(jìn)行認(rèn)識(shí)：（引自：tools.ietf.org/）

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (mac) and/or encrypted.

從摘要中的描述基本可以明確，JWT 僅僅是在于兩個(gè)部分之間進(jìn)行傳輸聲明的一種 compact 和 url-safe 的方式。

compact 是指針對(duì)于體積上，通過(guò) JWT 進(jìn)行簽名和加密的結(jié)果體積比較小，在傳輸過(guò)程中減少帶寬的負(fù)載。

url-safe 是指針對(duì)對(duì)應(yīng)的加密算法，在加密和解密的結(jié)構(gòu)上，相對(duì)來(lái)說(shuō) JWT 處理的信息更加安全。

它能夠防止一定程度的攻擊，如下情況。

情況 1：

如果在 html 中一樣可以輕松地植入，比如：

將上圖中的某一個(gè) img 標(biāo)簽對(duì)應(yīng) i 的的 src 屬性進(jìn)行替換就會(huì)改變執(zhí)行的請(qǐng)求，導(dǎo)致如下圖中的修改：

可以看到，jwt.io 在這種簡(jiǎn)單的操作中，對(duì)應(yīng)的 logo 就被替換掉了，如果換得 URL 不是一個(gè)圖片，而是一個(gè)關(guān)于用戶/權(quán)限/或者支付的業(yè)務(wù)，那結(jié)果是很可怕的。

有很多人對(duì) CSRF（cross-site request forgery）沒有明確的概念，上面的這個(gè)例子，就能簡(jiǎn)單的證明 CSRF 帶來(lái)的危害。

情況 2：

如果寫在 cookie 里，可以很容截獲，比如下：

在瀏覽器中通過(guò) F12 彈出的開發(fā)者工具中，選擇 Application 左側(cè)的 Cookie 選項(xiàng)，雙擊右側(cè)的鍵值對(duì)就可以修改，這種方式會(huì)導(dǎo)致 cookie，或者 local storage 中存入的信息被泄露或者修改。

但是對(duì)于跨站腳本的攻擊，依然起不到作用，也就是 XSS（Cross-Site Scripting），通過(guò)腳本注入可以像瀏覽器中植入腳本對(duì) cookie/local storage 中的信息進(jìn)行獲取或者修改。具體方式就不再說(shuō)明（考慮到被惡意使用進(jìn)行攻擊，這里只需要知道會(huì)出現(xiàn)這種情況）

另外對(duì)于 JWT 還有一個(gè)常見的錯(cuò)誤認(rèn)識(shí)：

可能有些同學(xué)會(huì)認(rèn)為，在 http://jwt.io 上使用的時(shí)候會(huì)認(rèn)為，既然可以 encode，也可以 decode，那么這種情況下，對(duì)于簽名和驗(yàn)簽還有什么意義。

但是實(shí)際上并不是我們想象的那樣，在使用 secret 簽名過(guò)后，在驗(yàn)簽的時(shí)候，secret 是無(wú)法被反向解析出來(lái)的。

如下：

1. header

{
  "alg": "HS256",
  "typ": "JWT"
}

2. payload

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

3. secret

test

4. encode 后的內(nèi)容：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MdiyfQ.5mhBHqs5_DTLdINd9p5m7ZJ6XD0Xc55kIaCRY5r6HRA

用點(diǎn)符號(hào)和換行符變成易讀格式：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
5mhBHqs5_DTLdINd9p5m7ZJ6XD0Xc55kIaCRY5r6HRA

上述過(guò)程是編碼的過(guò)程，下面觀察解碼的過(guò)程：

1. 清空 decoded 下的對(duì)應(yīng)信息

2. 將上述編碼后的內(nèi)容，放到 encoded 下的文本框

加上 secret 后才能夠完成簽名的驗(yàn)證。這種情況下意味著，如果獲取到 token 的惡意用戶，即使竊取信息后再次發(fā)送，修改任何一個(gè)參數(shù)，都無(wú)法正確的進(jìn)行驗(yàn)簽。

所以很重要的一點(diǎn)，就是 signature 的簽名，如果沒有密鑰的話，是無(wú)法進(jìn)行可逆解析的，否則這個(gè)簽名過(guò)程就沒有意義了。

對(duì)于 JWT 的進(jìn)一步認(rèn)識(shí)可以參考如下開源代碼：

https://github.com/jwt-dotnet/jwt

https://github.com/dvsekhvalnov/jose-jwt

相比于官方提供的 jose-jwt 的 .NET 版本，Jwt.Net 的封裝相對(duì)來(lái)說(shuō)使用起來(lái)，要稍微麻煩一點(diǎn)，但是它的優(yōu)勢(shì)在于對(duì) .NET CORE 和 .NET OWIN 有對(duì)應(yīng)的擴(kuò)展。而 jose-jwt 提供的只有加密和解密的過(guò)程。

但是個(gè)人認(rèn)為相對(duì)來(lái)說(shuō)，官方提供的源碼更加有助于對(duì) JWT，以及相關(guān)標(biāo)準(zhǔn)進(jìn)行理解。而且提供的源碼不局限于 .NET。

以上就是對(duì)于 JWT 的基本信息的一些了解和說(shuō)明。它和授權(quán)的關(guān)系并沒有直接關(guān)系，只是在授權(quán)過(guò)程中，比如在 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
draft-ietf-oauth-access-token-jwt-03 中就將 access tokens 和 JWT 進(jìn)行了結(jié)合。

（圖片引用自：tools.ietf.org 的截圖)

C Sharp 的 OWIN 中間件

這里提到的 OWIN 中間件，是在 C# 進(jìn)行 OAuth 2.0 環(huán)境的搭建過(guò)程中使用的中間件，對(duì)于它的基本介紹如下：

使用 OAuth 2.0 framework，第三方應(yīng)用可以獲得對(duì) HTTP 服務(wù)的有限訪問權(quán)限。客戶端不使用資源所有者的憑據(jù)來(lái)訪問受保護(hù)的資源, 而是獲取一個(gè)訪問令牌（表示特定范圍、生存期和其他訪問屬性的字符串）。授權(quán)服務(wù)器將訪問令牌頒發(fā)給第三方客戶端，并批準(zhǔn)資源所有者。

OWIN 定義 .NET Web 服務(wù)器和 Web 應(yīng)用程序之間的標(biāo)準(zhǔn)接口。 OWIN 接口的目標(biāo)是將服務(wù)器和應(yīng)用程序分離，鼓勵(lì)開發(fā)簡(jiǎn)單的 .NET Web 開發(fā)模塊，并通過(guò)作為開放標(biāo)準(zhǔn)來(lái)鼓勵(lì) .NET Web 開發(fā)工具的開源生態(tài)系統(tǒng)。

來(lái)自：

https://docs.microsoft.com/zh-cn/aspnet/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server

在 NuGet 解決方案中搜索

Microsoft.Owin.Security.OAuth

從圖中右側(cè)標(biāo)注的紅框部分，可以看到對(duì)應(yīng)的 GitHub 上的源碼，對(duì)詳細(xì)的過(guò)程進(jìn)行剖析。比如：

用戶信息賦值的關(guān)鍵點(diǎn)，在這里對(duì) token 進(jìn)行驗(yàn)證，如果驗(yàn)證不通過(guò)的情況之下，將無(wú)法通過(guò)：

在開發(fā)過(guò)程中可能還會(huì)遇到問題就是即使所有的地方都配置好了，但是死活驗(yàn)證不通過(guò)，原因是依賴的 dll 沒有引入完整，但是也沒有報(bào)錯(cuò)，導(dǎo)致的。參考下面的圖中對(duì)應(yīng)的 dll。

面試題

OAuth 2.0 是不是身份認(rèn)證協(xié)議
OAuth 2.0 中有哪幾種授權(quán)類型
授權(quán)碼授權(quán)于隱式授權(quán)類型之間的區(qū)別
CAS 與 SSO 之間存在什么樣的關(guān)系

對(duì)于這幾個(gè)問題，在上述內(nèi)容中均能夠找到答案。

很多知識(shí)點(diǎn)在總結(jié)的過(guò)程中發(fā)現(xiàn)，一個(gè)篇幅不能夠面面俱到，尤其對(duì)于授權(quán)和認(rèn)證的具體實(shí)現(xiàn)過(guò)程，不同實(shí)現(xiàn)方式的特點(diǎn)，為了能夠有具體的可操作的解決方案，后續(xù)會(huì)總結(jié)出詳細(xì)過(guò)程步驟以專欄的形式分章節(jié)列出。有不足的地方歡迎指正。