安全認(rèn)證機(jī)制
最近項(xiàng)目要用到安全驗(yàn)證了历涝，以前的實(shí)現(xiàn)方式都是單個(gè)服務(wù)模式诅需，加攔截器和cookie即可⊙Γ現(xiàn)在在微服務(wù)上需要實(shí)現(xiàn)單點(diǎn)登錄，重寫了解一下認(rèn)證機(jī)制堰塌。
1. HTTP Basic Auth
最簡單的一種實(shí)現(xiàn)赵刑，每次請(qǐng)求API都提供用戶的賬號(hào)與密碼。但這種方式會(huì)有信息暴露風(fēng)險(xiǎn)场刑。使用的越來越少般此。
2. OAuth
OAuth(開放授權(quán))是一個(gè)開放的授權(quán)標(biāo)準(zhǔn)，允許用戶讓第三方應(yīng)用訪問該用戶在某一服務(wù)器上的資源牵现，而無需將用戶名和密碼提供給第三方應(yīng)用恤煞。如：微信/QQ登錄第三方網(wǎng)站等。
OAuth允許用戶提供一個(gè)令牌施籍，而不是賬號(hào)和密碼來訪問用戶的數(shù)據(jù)居扒。每一個(gè)令牌授權(quán)一個(gè)特定的第三方系統(tǒng)在特定的時(shí)間段內(nèi)訪問特定的資源。丑慎。這 樣喜喂，OAuth讓用戶可以授權(quán)第三方網(wǎng)站訪問他們存儲(chǔ)在另外服務(wù)提供者的某些特定信 息，而非所有內(nèi)容竿裂。
OAuth2.0流程如下：
3. Cookie-Session 機(jī)制
????該機(jī)制為一次請(qǐng)求認(rèn)證在服務(wù)端創(chuàng)建一個(gè)Session對(duì)象玉吁，同時(shí)在客戶端創(chuàng)建一個(gè)Cookie對(duì)象。通過客戶端上帶來的Cookie與服務(wù)端的Session對(duì)象匹配來實(shí)現(xiàn)狀態(tài)管理腻异。cookie與session可以設(shè)置過期時(shí)間进副。
4. JWT實(shí)現(xiàn)令牌(token)
????一種無狀態(tài)的方式，在服務(wù)端不需要存儲(chǔ)用戶的登錄記錄悔常。
流程如下：
????客戶端使用用戶名與密碼登錄
????服務(wù)端收到請(qǐng)求影斑，驗(yàn)證用戶名與密碼
????驗(yàn)證成功后，服務(wù)端簽發(fā)一個(gè)token机打，再把token發(fā)送給客戶端
????客戶端收到并存儲(chǔ)token矫户，如放在cookie中 ，發(fā)送的時(shí)候它應(yīng)該保存在請(qǐng)求頭里
????客戶端每次去訪問服務(wù)器帶著token
????服務(wù)器收到請(qǐng)求残邀，驗(yàn)證token皆辽，如果驗(yàn)證成功，就返回響應(yīng)
5. Token對(duì)于Cookie機(jī)制的好處
????支持跨域訪問: Cookie是不允許垮域訪問的芥挣，這一點(diǎn)對(duì)Token機(jī)制是不存在的驱闷，前提 是傳輸?shù)挠脩粽J(rèn)證信息通過HTTP頭傳輸.
????無狀態(tài)(也稱：服務(wù)端可擴(kuò)展行):Token機(jī)制在服務(wù)端不需要存儲(chǔ)session信息，因?yàn)?Token 自身包含了所有登錄用戶的信息空免，只需要在客戶端的? ?cookie或本地介質(zhì)存儲(chǔ) 狀態(tài)信息.
????更適用CDN: 可以通過內(nèi)容分發(fā)網(wǎng)絡(luò)請(qǐng)求你服務(wù)端的所有資料（如：javascript空另， HTML,圖片等），而你的服務(wù)端只要提供API即可.
????去耦: 不需要綁定到一個(gè)特定的身份驗(yàn)證方案鼓蜒。Token可以在任何地方生成痹换，只要在 你的API被調(diào)用的時(shí)候，你可以進(jìn)行Token生成調(diào)用即可.
????擴(kuò)展性: 使用session用戶認(rèn)證之后都弹，服務(wù)端做認(rèn)證記錄娇豫，如果認(rèn)證的記錄被保存在內(nèi)存中的話，這意味著用戶下次請(qǐng)求還必須要請(qǐng)求在這臺(tái)服務(wù)器上,這樣才能拿到授權(quán)的資源畅厢，這樣在分布式的應(yīng)用上冯痢，相應(yīng)的限制了負(fù)載均衡器的能力。這也意味著限制了應(yīng)用的擴(kuò)展能力框杜。
????更適用于移動(dòng)應(yīng)用: 當(dāng)你的客戶端是一個(gè)原生平臺(tái)（iOS, Android浦楣，Windows 8等） 時(shí)，Cookie是不被支持的（你需要通過Cookie容器進(jìn)行處理）咪辱，這時(shí)采用Token認(rèn) 證機(jī)制就會(huì)簡單得多振劳。
????CSRF:因?yàn)椴辉僖蕾囉贑ookie，所以你就不需要考慮對(duì)CSRF（跨站請(qǐng)求偽造）的防 范油狂。
????性能: 一次網(wǎng)絡(luò)往返時(shí)間（通過數(shù)據(jù)庫查詢session信息）總比做一次HMACSHA256 計(jì)算 的Token驗(yàn)證和解析要費(fèi)時(shí)得多.
????不需要為登錄頁面做特殊處理: 如果你使用Protractor 做功能測試的時(shí)候历恐，不再需要 為登錄頁面做特殊處理.
????基于標(biāo)準(zhǔn)化:你的API可以采用標(biāo)準(zhǔn)化的 JSON Web Token (JWT). 這個(gè)標(biāo)準(zhǔn)已經(jīng)存在 多個(gè)后端庫（.NET, Ruby, Java,Python, PHP）和多家公司的支持
6. JWT
????JSON Web Token: 三部分組成：header+payload+signature
????頭信息指定了該JWT使用的簽名算法:
????header = '{"alg":"HS256","typ":"JWT"}'
????消息體包含了JWT的意圖，包含一些需要傳輸?shù)南ⅲ?/p>
????????payload = '{"loggedInAs":"admin","iat":1422779638}'//iat表示令牌生成的時(shí)間
????未簽名的令牌由base64url編碼的頭信息和消息體拼接而成（使用"."分隔）专筷，簽名則通過私有的key計(jì)算而成：
????????key='secretkey'//服務(wù)器的私鑰
????????unsignedToken=encodeBase64(header)+'.'+encodeBase64(payload)
????????signature=HMAC-SHA256(key, unsignedToken)
????最后在未簽名的令牌尾部拼接上base64url編碼的簽名（同樣使用"."分隔）就是JWT了：
????????token=encodeBase64(header)+'.'+encodeBase64(payload)+'.'+encodeBase64(signature)
?
????# token看起來像這樣: ????????eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
????一般使用為Authorization: Bearer token串形式
CSRF 簡介
CSRF攻擊攻擊原理及過程如下：
? ? 1. 用戶C打開瀏覽器弱贼，訪問受信任網(wǎng)站A，輸入用戶名和密碼請(qǐng)求登錄網(wǎng)站A磷蛹；
? ? 2.在用戶信息通過驗(yàn)證后吮旅，網(wǎng)站A產(chǎn)生Cookie信息并返回給瀏覽器，此時(shí)用戶登錄網(wǎng)站A成功味咳，可以正常發(fā)送請(qǐng)求到網(wǎng)站A庇勃；
? ? 3. 用戶未退出網(wǎng)站A之前，在同一瀏覽器中槽驶，打開一個(gè)TAB頁訪問網(wǎng)站B匪凉；
? 4. 網(wǎng)站B接收到用戶請(qǐng)求后，返回一些攻擊性代碼捺檬，并發(fā)出一個(gè)請(qǐng)求要求訪問第三方站點(diǎn)A再层；
? 5. 瀏覽器在接收到這些攻擊性代碼后，根據(jù)網(wǎng)站B的請(qǐng)求堡纬，在用戶不知情的情況下攜帶Cookie信息聂受，向網(wǎng)站A發(fā)出請(qǐng)求。網(wǎng)站A并不知道該請(qǐng)求其實(shí)是由B發(fā)起的烤镐，所以會(huì)根據(jù)用戶C的Cookie信息以C的權(quán)限處理該請(qǐng)求蛋济，導(dǎo)致來自網(wǎng)站B的惡意代碼被執(zhí)行。
(一般情況下炮叶，關(guān)閉網(wǎng)頁后cookie即被刪除)
