相信關(guān)注過CAS和OAuth2.0協(xié)議的朋友們，都有大概的了解，簡單描述兩個協(xié)議的主要區(qū)別，網(wǎng)上的伙伴們通常會說：

而對于單點登錄場景來說，無論是保護客戶端資源，還是保護服務(wù)端資源，最終都是完成認(rèn)證中心的認(rèn)證，使訪問的資源獲取到登錄的用戶信息，從這個角度來看，兩個協(xié)議并沒有什么區(qū)別。

那么在怎樣去理解兩種的區(qū)別呢？先來看一下兩個協(xié)議：

說到CAS協(xié)議，必須亮出下圖：

1、訪問服務(wù)：SSO 客戶端發(fā)送請求訪問應(yīng)用系統(tǒng)提供的服務(wù)資源。

2、定向認(rèn)證：SSO 客戶端會重定向用戶請求到 SSO 服務(wù)器。

3、用戶認(rèn)證：用戶身份認(rèn)證。

4、發(fā)放票據(jù)：SSO 服務(wù)器會產(chǎn)生一個隨機的 Service Ticket 。

5、驗證票據(jù)：SSO 服務(wù)器驗證票據(jù) Service Ticket 的合法性，驗證通過后，允許客戶端訪問服務(wù)。

6、傳輸用戶信息：SSO 服務(wù)器驗證票據(jù)通過后，傳輸用戶認(rèn)證結(jié)果信息給客戶端。

交互過程中1、2、3、4步驟是通過客戶端網(wǎng)傳輸?shù)?，存在安全隱患，可以看出其中3和4步攜帶有敏感數(shù)據(jù)，3用戶認(rèn)證是最基本的場景由CAS Server保障認(rèn)證安全，4重定向到CAS Client的過程攜帶有認(rèn)證核心票據(jù)Service Ticket（有時效性的，可重復(fù)使用的），安全性由CAS Client保障，為了保障這兩步的信息傳輸安全，要求CAS Client 和CAS Server端都采用Https方式訪問進行傳輸加密，因為一旦Service Ticket被攔截，則可以模仿認(rèn)證成功的請求，欺騙CAS Client用戶已完成認(rèn)證，并進一步完成后續(xù)的認(rèn)證交互。

本文以碼模式（authorization code）的交互進行對比：

1、用戶訪問業(yè)務(wù)系統(tǒng)。

2、業(yè)務(wù)系統(tǒng)判斷用戶沒有登錄，把用戶重定向到認(rèn)證中心進行認(rèn)證。

3、用戶在認(rèn)證中心完成登錄認(rèn)證，IAM為用戶的此次請求創(chuàng)建OAuth code，并帶OAuth code返回應(yīng)用回調(diào)地址。

4、應(yīng)用獲取OAuth code并和約定的密鑰一起通過服務(wù)器間請求，獲取Access Token。

5、應(yīng)用通過Access Token調(diào)用用戶接口獲取用戶信息。

6、應(yīng)用得到用戶身份，完成用戶登錄。

交互過程中1、2、3是通過客戶端網(wǎng)絡(luò)傳輸?shù)?，存在安全隱患，但是因為這三步的目的是獲取code，而獲取的code是一次性有效的，并無法單獨使用，須要與第4步中的約定密鑰一起使用獲取token信息，所以安全性有一定的保障，業(yè)務(wù)系統(tǒng)須要保管好密鑰，并保障密鑰不從客戶端傳輸，僅在服務(wù)器間傳輸。

綜上所述，無論是CAS協(xié)議的認(rèn)證集成還是OAuth2.0的認(rèn)證集成，都需要業(yè)務(wù)系統(tǒng)和認(rèn)證中心通過https協(xié)議保障客戶端http請求的安全性，而CAS協(xié)議這一點尤為重要，因為保障Service Ticket的安全性*依賴于https 的SSL協(xié)議保障，而OAuth2.0在此基礎(chǔ)上，還有額外的兩個約束：1、code次數(shù)有效性約束；2、換取token時須要提供約定密鑰。