涉及內容：CAS、SSO、Oauth2.0，token、XSS、CSRF。

名詞科普

• Oauth2.0：Oauth是一個關于授權的開放標準網絡協議，目前的版本是2.0。
• CAS(Central Authentication Service) 中心認證服務。
• SSO(Single Sign On) 單點登錄。
• token：一個主服務允許第三方訪問特定資源的令牌。
• CSRF(Cross-site request forgery)跨站請求偽造。
• XSS(Cross Site Scripting)跨站腳本攻擊。

在使用任何登錄框架或者傳輸標準時，如果想安全，都要基于HTTPS協議！

Oauth2.0

原理解釋

場景：你在（登錄后）瀏覽某論壇時，遇到了一篇好文章，想要分享給大家時，你需要登錄（掃碼或者登錄用戶名密碼）第三方賬戶來完成分享。
基本流程：

1. 在點擊分享鏈接時，主服務器會直接（接口）請求第三方服務器，第三方服務器會校驗主服務器上的用戶此時是否授權給自己（第三方）；
2. 沒有授權信息，用戶登錄（掃描或者密碼）。
3. 主服務器拿著用戶的登錄信息去第三方確認認證授權（密碼是否正確、是否授權）。
4. 認證失敗，密碼錯誤。（重新登錄）
5. 認證成功（確認授權），第三方認證服務會返回的授權碼。
6. 主服務器帶著授權碼請求第三方資源服務器，第三方資源服務器會返回指定的URI（分享界面）。
7. 用戶操作分享操作（填寫自己的話語），點擊分享按鈕完成。

在整個流程中，涉及的角色有：Resource Owner（用戶）、Resource Server、Client、Authorization Server。其中：
??認證的登錄界面是主服務器提供；
??用戶的最終操作界面（本例中為分享頁面），為第三方服務提供的界面（接口）。

【此處缺圖】

針對于用戶的授權，Oauth2.0提供了四種方式：

• 授權碼模式（authorization code）
• 簡化模式（implicit）
• 密碼模式（resource owner password credentials）
• 客戶端模式（client credentials）

因考慮到authorization code方式是最嚴謹、最廣泛、最貼近于服務器端的一種認證方式，所以只介紹著一種認證方式。

authorization code
適用場景：此類型可用于有服務端的應用，是最貼近老版本的方式。
【此處缺圖】

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

（A）用戶打開客戶端以后，客戶端要求用戶給予授權。
（B）用戶同意給予客戶端授權。
（C）客戶端使用上一步獲得的授權，向認證服務器申請令牌。
（D）認證服務器對客戶端進行認證以后，確認無誤，同意發放令牌。
（E）客戶端使用令牌，向資源服務器申請獲取資源。
（F）資源服務器確認令牌無誤，同意向客戶端開放資源。

說明：
Client Identifier是需要在第三方審核通過所得。
Redirection URI是成功之后，客戶端希望認證服務器跳轉到的頁面，一般來說，該頁面由客戶端提供。整個流程一共傳遞了兩次Redirection URI，是為了防止Authorization Code被別人獲取，而從第三方服務器端直接重定向。
其中access token是訪問調用第三方應用的憑證。因考慮到access token 的有效時長短，會有使用refresh token來（調用自定義接口）進行刷新并獲取新的access token。refresh token也可以有時效，一般設置為一個月。生成也很簡單，唯一的信息自定義轉碼方式即可生成。
state用于保持請求和回調的狀態，授權請求后原樣帶回給第三方。該參數可用于防止csrf攻擊（跨站請求偽造攻擊），建議第三方帶上該參數，可設置為簡單的隨機數加session進行校驗。
登錄操作是在第二步來完成的。認證服務器檢測到用戶未登錄，會跳轉到登錄頁面。

CAS講解

CAS只支持HTTPS協議。

共涉及角色有：CAS Client（下文提到的系統A等）、User、CAS Server（認證中心）。

【此處缺圖】

流程：
1）用戶訪問系統A；
2）系統A發現用戶沒有登錄，也沒有ticket，重定向到認證中心；有ticket跳轉 第7）步；
3）認證中心發現用戶并未登錄，展示登錄頁面；
4）用戶登錄；
5）認證中心登錄成功，帶著生成的ticket，重定向到之前的系統A頁面；
6）系統A檢查登錄，還是未登錄，但存在ticket。系統A帶著ticket和認證中心進行校驗；
7）認證中心返回對應的用戶名；
8）系統A檢查返回的用戶名是否只有一個且不為空，若是，則返回給用戶指定的資源信息；若不是，則跳轉 第2）步。

注意事項：

1. 登錄狀態的判斷：子系統不可能每次都和認證中心進行校驗，所以需要有局部session。而認證中心生成的Session為全局Session。
2. 登出：局部Session依附于全局Session，當全局Session注銷，局部Session也不存在；當局部Session被注銷（用戶登出），全局Session也不應該存在。
3. 在重定向的過程中，如后續還需要二次重定向，需要獲取前端URL地址作為參數傳遞給第一次重定向的服務器。
4. 在登錄了A系統后，服務端會存在一個TGT（ticket generated ticked），客戶端會存在一個TGC(ticket generated cookie)。TGT是票據生成票據。TGC內存了一個服務器上TGT的id。在登錄B系統時，服務器會查詢本地是否存在TGC，若存在，直接獲取該TGC。

CSRF

攻擊者盜用你的名義，執行操作。

image

從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個步驟：
1.登錄受信任網站A，并在本地生成Cookie。
2.在不登出A的情況下，訪問危險網站B。

Spring Security提供的結局方案是：Synchronizer Token Pattern。

XSS

在你的頁面，（利用script的立即執行，）執行我想要執行的JS代碼。

本文中參考地址：
Oath2.0參考：微信API文檔、OAuth的改變、理解OAuth 2.0。
CAS參考：CAS與SSO探究、SSO CAS單點系列-慕課。
CSRF參考：https://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html 。
XSS參考：http://netsecurity.51cto.com/art/201408/448305_all.htm。