技術(shù)干貨 | 單點(diǎn)登錄場(chǎng)景中的CAS協(xié)議和OAuth2.0協(xié)議對(duì)比

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

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

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

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

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

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

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

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

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

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

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

本文以授權(quán)碼模式（authorization code）的交互進(jìn)行對(duì)比：

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

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

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

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

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

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

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

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