Token的生成方式或常見樣式有：

• 隨機(jī)字符串（UUID）
• 按照J(rèn)WT標(biāo)準(zhǔn)生成（按一定標(biāo)準(zhǔn)生成加密串）
• 直接將相關(guān)信息做加密
• SpringSecurity生成：在過濾器中過濾請求，生成或校驗(yàn)Token，默認(rèn)用UUID生成，并將Token存于Cookie或Session中

Token常見作用：

• 防止表單重復(fù)提交，保證請求的冪等性：

處理一個(gè)請求，將其Token存入“已處理請求”中，再次進(jìn)來的請求，如果其Token已在“已處理請求中”，則不再重復(fù)處理（該Token需要盡量保證全局唯一）

• CSRF防御：

Token由服務(wù)端返回，將Token存入Cookie或者Session中，并存入到返回的html中表單的hidden字段中，等提交表單時(shí)，服務(wù)端對比表單提交的請求參數(shù)中的token與cookie或session中存儲的token是否一致。

場景：服務(wù)端收到訪問/login頁面請求時(shí)

1. 先檢查Cookie或Session中是否已經(jīng)存在Token，存在則直接將該Token存入返回的html表單中；不存在則通過SpringSecurity生成（其他方式生成也行），將Token存入Cookie或Session中，并將該Token存入返回的html表單中
2. 瀏覽器顯示/login的頁面
3. 在/login中提交表單，會把隱藏字段中的Token一并提交
4. 服務(wù)端校驗(yàn)請求參數(shù)中的Token與Cookie或Session中存儲的Token是否一致

Token是動(dòng)態(tài)變化的，CSRF的表單無法確定當(dāng)前的Token是什么，也就無法提前準(zhǔn)備請求參數(shù)，一定程度上實(shí)現(xiàn)了CSRF的防御。

• 單點(diǎn)登錄（SSO）

初次登陸，服務(wù)端按照指定字段生成Token（直接加密，或者用JWT標(biāo)準(zhǔn)加密都行），并返回，下次訪問時(shí)請求中帶上指定字段和Token，服務(wù)端將Token解密，如果解密結(jié)果與請求中攜帶的指定字段一致，則允許訪問。（此Token存于請求頭中，因此跨域訪問也會生效，如果存在Cookie中，跨域訪問Cookie會失效）

以加密方式生成Token的好處：

分布式中，每個(gè)服務(wù)端存儲加密算法及密鑰即可，無需通過Session存儲，減輕服務(wù)端壓力。

使用加密算法的注意點(diǎn)：

無論是JWT標(biāo)準(zhǔn)中的加密，還是用AES或者3DES等加密算法，加密后都需要用base32，或者base64編碼，同理解密前，也要先用base解碼，再解密。

因?yàn)椋用芎蟮淖址泻芏嘤?jì)算機(jī)無法顯示的亂碼，通過url返回時(shí)，甚至后續(xù)如果要將加密串存入數(shù)據(jù)庫，這些計(jì)算機(jī)無法識別的字符都有可能出現(xiàn)問題，因此需要用base編碼。

同時(shí)也要注意，用base64編碼時(shí)，主要base64中的‘+’、‘/’及最后自動(dòng)生成的占位符‘=’，這些都是在url中的特殊字符，在存入url時(shí)會產(chǎn)生異議，因此需要做額外的特殊處理。