授權和認證是每個項目中不可或缺的一部分，脆弱的授權、認證流程會在惡意攻擊中不堪一擊，會在項目運行過程中無法承受高流量的沖擊。在這個環節中，OAuth 認證、SSO 單點登錄、CAS 中央認證服務會頻繁地出現在相關業務的開發人員視野中，可是總是多多少少的懵懵懂懂。

這里筆者會盡力從源頭上解決對于相關概念的理解，以及在項目中的實踐。并且收錄部分面試過程中會遇到的問題。

旨在解決相關人員對于概念的深入理解，對于項目的實踐認識，對于面試的關鍵點剖析。單個篇幅無法做到面面俱到，盡力估計，過程中會提供 JAVA、C Sharp 的代碼解釋。

在本場 Chat 中，會講到如下內容：

OAuth 的說明、應用
SSO 單點登錄的說明、應用
CAS 的說明應用
JWT 和授權的關系
C# 中間件 OWIN
常見授權認證相關的面試題收集、剖析

OAuth 的說明、應用

OAuth 是什么

在維基百科中對于 OAuth 的解釋如下：

開放授權（OAuth）是一個開放標準，允許用戶讓第三方應用訪問該用戶在某一網站上存儲的私密的資源（如照片、視頻、聯系人列表），而無需將用戶名和密碼提供給第三方應用。

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

OAuth 是 OpenID 的一個補充，但是完全不同的服務。

在百度百科中對于 OAuth 的解釋如下：

OAuth 協議為用戶資源的授權提供了一個安全的、開放而又簡易的標準。與以往的授權方式不同之處是 OAuth 的授權不會使第三方觸及到用戶的帳號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權，因此 OAuth 是安全的。OAuth 是 Open Authorization 的簡寫。

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

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

在 IETF 組織中的對于 OAuth 2.0 Authorization Framework 對應的摘要描述如下：

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.

通過這幾個方面的查看，可以明確的消除對于 OAuth 的錯誤認識，OAuth 不是一個技術框架，也不是一個 jar 包，也不是一個 dll 程序集，它僅僅是一個 protocol，被翻譯為協議、標準、或者規則。這只是對于 OAuth 的一個宏觀認識。

在 oauth.net 中的簡介可以了解到，OAuth 2.0 是允許通過使用簡單標準的方法從 Web、移動和桌面應用程序中進行安全授權的開放協議。

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

上面是對 OAuth 以及 OAuth 2.0 的宏觀認識，下面對于 OAuth 2.0 包括的幾種方式進行介紹。

（圖片來自 tools.ietf.org 的截圖）

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

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

這也是 OAuth 2.0 區別于 OAuth 1.0 的地方，OAuth 2.0 中工作組所作出的明確決定是，它不再是一個單個協議，而是一個框架。從名字上也可以看出來，1.0 是 protocol，而 2.0 的標題是 framework。

授權碼授予類型

授權碼類型是目前 OAuth 2.0 中最常用，最安全的一種類型。通過去授權端獲取授權碼，利用授權碼換取 token，通過使用 token 去資源服務器獲取受保護資源。

以阿里云的內容協作平臺 CCP 的官方文檔為實例：

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

隱式授權類型

Implicit Grant 有的地方被翻譯成簡單授權，但是筆者認為翻譯成簡單授權有點偏離原有的意思。它只是針對授權碼的環節做了一定簡化，但是它的使用并不能被視為簡單的授權類型。

授權碼流程的不同步驟的關鍵之處，在于能夠保持不同組件之間的分離，瀏覽器不知道客戶端應該知道的內容，客戶端無法獲取到瀏覽器的狀態。但是，如果把客戶端放到瀏覽器中，該怎么辦呢？這種情況在目前的 SPA 單頁面應用程序中經常會出現。客戶端執行的所有過程，由于都是基于瀏覽器實現的，所以幾乎相當于在瀏覽器上裸奔。

（圖片引用 OAuth 2.0 in Action）

使用這種方法，沒有現實的方法來保護客戶端的密碼信息，因為它需要對于瀏覽器可用才能執行后續流程。

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

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

以阿里云的內容協作平臺 CCP 的官方文檔為實例：

（圖片引用 help.aliyun.com）

客戶端憑證授權類型

（圖片引用 OAuth 2.0 in Action）

在 RFC 中是這么進行描述的：

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

實際上是一個道理，只是表現形式稍微有一點不同而已。客戶端直接對它自己進行驗證，然后授權服務器頒發適當的令牌。

資源所有者授予類型

（圖片引用 OAuth 2.0 in Action）

通過使用 Resource Owner 的用戶名和密碼來換取令牌，這種方式一般是不提倡使用的，原因是當用戶名和密碼暴露出來的時候，就自然會導致攻擊面變得更大，風險更高。

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

以上就是對于 OAuth 的說明，以及 OAuth 2.0 framework 中涉及到的幾種類型的圖示和描述，以及在實際場景中的應用流程。

對于代碼 OAuth 2.0 的具體實現過程，由于每一個環節都涉及很多內容，不在編碼過程中消化就會很難理解，后續將會在專欄中進行詳細過程的剖析。這里通過概念的引入和宏觀的理解，消除平時工作過程中對于概念的錯誤認識。

SSO 的說明和應用

SSO，single sign on 單點登錄，單點登錄為用戶提供無縫的身份驗證體驗。在構建的應用程序中，一旦登錄這些應用程序中的一個，當使用其他應用程序的情況下，不需要再次登錄。反之，在登出的過程中，只要一個應用程序登出，那么所有應用對應的登錄狀態全是登出。

這就是 SSO，單點登錄的基本含義。

CAS

CAS，Central Authentication Service，集中式身份驗證。SSO 和 CAS 是密不可分的，SSO 可以理解為一個軟件系統，而 CAS 是作為實現 SSO 的一種解決方案。更準確的來說，它是一個規范性質的協議。

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

對應的 C sharp 的源碼可以參考如下的 GitHub 源碼，地址為：

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

對應 Java 的源碼可以參考如下 GitHub 的源碼，地址為：

https://github.com/apereo/cas

JWT 和授權的關系

首先要知道的可能是 JWT 是什么？這個概念在很多地方，要么是沒有被解釋，要么是被結合場景使用的解釋，偏離了它本身的概念。那么參考 IETF 的說明來對 JWT 的本質進行認識：（引自：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 僅僅是在于兩個部分之間進行傳輸聲明的一種 compact 和 url-safe 的方式。

compact 是指針對于體積上，通過 JWT 進行簽名和加密的結果體積比較小，在傳輸過程中減少帶寬的負載。

url-safe 是指針對對應的加密算法，在加密和解密的結構上，相對來說 JWT 處理的信息更加安全。

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

情況 1：

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

將上圖中的某一個 img 標簽對應 i 的的 src 屬性進行替換就會改變執行的請求，導致如下圖中的修改：

可以看到，jwt.io 在這種簡單的操作中，對應的 logo 就被替換掉了，如果換得 URL 不是一個圖片，而是一個關于用戶/權限/或者支付的業務，那結果是很可怕的。

有很多人對 CSRF（cross-site request forgery）沒有明確的概念，上面的這個例子，就能簡單的證明 CSRF 帶來的危害。

情況 2：

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

在瀏覽器中通過 F12 彈出的開發者工具中，選擇 Application 左側的 Cookie 選項，雙擊右側的鍵值對就可以修改，這種方式會導致 cookie，或者 local storage 中存入的信息被泄露或者修改。

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

另外對于 JWT 還有一個常見的錯誤認識：

可能有些同學會認為，在 http://jwt.io 上使用的時候會認為，既然可以 encode，也可以 decode，那么這種情況下，對于簽名和驗簽還有什么意義。

但是實際上并不是我們想象的那樣，在使用 secret 簽名過后，在驗簽的時候，secret 是無法被反向解析出來的。

如下：

1. header

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

2. payload

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

3. secret

test

4. encode 后的內容：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MdiyfQ.5mhBHqs5_DTLdINd9p5m7ZJ6XD0Xc55kIaCRY5r6HRA

用點符號和換行符變成易讀格式：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
5mhBHqs5_DTLdINd9p5m7ZJ6XD0Xc55kIaCRY5r6HRA

上述過程是編碼的過程，下面觀察解碼的過程：

1. 清空 decoded 下的對應信息

2. 將上述編碼后的內容，放到 encoded 下的文本框

加上 secret 后才能夠完成簽名的驗證。這種情況下意味著，如果獲取到 token 的惡意用戶，即使竊取信息后再次發送，修改任何一個參數，都無法正確的進行驗簽。

所以很重要的一點，就是 signature 的簽名，如果沒有密鑰的話，是無法進行可逆解析的，否則這個簽名過程就沒有意義了。

對于 JWT 的進一步認識可以參考如下開源代碼：

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

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

相比于官方提供的 jose-jwt 的 .NET 版本，Jwt.Net 的封裝相對來說使用起來，要稍微麻煩一點，但是它的優勢在于對 .NET CORE 和 .NET OWIN 有對應的擴展。而 jose-jwt 提供的只有加密和解密的過程。

但是個人認為相對來說，官方提供的源碼更加有助于對 JWT，以及相關標準進行理解。而且提供的源碼不局限于 .NET。

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