雙因素認(rèn)證
一般有以下三種方式進(jìn)行身份認(rèn)證
秘密認(rèn)證：例如常見(jiàn)的用戶名密碼，秘密問(wèn)題等（QQ早期找回密碼需要回答之前設(shè)置好的秘密問(wèn)題寝凌，第一個(gè)寵物的名字等等）
私人物品認(rèn)證：例如身份證性锭，信物（玉佩）列牺，手機(jī)贬堵、U盾等
生理認(rèn)證：視網(wǎng)膜带族，人臉锁荔，指紋等
同時(shí)采用以上任意兩種的認(rèn)證方式進(jìn)行認(rèn)證，就是雙因素認(rèn)證炉菲。一般最常見(jiàn)的是秘密+私人物品堕战。
銀行之前使用的U盾就是私人物品坤溃，隨著智能手機(jī)的流行拍霜，手機(jī)成為一個(gè)人必不可少的物品嘱丢，U盾被代替。
OAuth 2.0 and OpenID Connect
視頻學(xué)習(xí)資料https://www.youtube.com/watch?v=996OiexHze0
- OpenID Connect is for authentication
- OAuth 2.0 is for authorization
OIDC是OpenID Connect的簡(jiǎn)稱祠饺，OIDC=(Identity, Authentication) + OAuth 2.0越驻。它在OAuth2上構(gòu)建了一個(gè)身份層，是一個(gè)基于OAuth2協(xié)議的身份認(rèn)證標(biāo)準(zhǔn)協(xié)議道偷。
OAuth2提供了Access Token來(lái)解決授權(quán)第三方客戶端訪問(wèn)受保護(hù)資源的問(wèn)題缀旁；OIDC在這個(gè)基礎(chǔ)上提供了ID Token來(lái)解決第三方客戶端標(biāo)識(shí)用戶身份認(rèn)證的問(wèn)題。OIDC的核心在于在OAuth2的授權(quán)流程中勺鸦，一并提供用戶的身份認(rèn)證信息（ID Token）給到第三方客戶端并巍，ID Token使用JWT格式來(lái)包裝，得益于JWT（JSON Web Token）的自包含性换途，緊湊性以及防篡改機(jī)制懊渡，使得ID Token可以安全的傳遞給第三方客戶端程序并且容易被驗(yàn)證。此外還提供了UserInfo的接口军拟，用戶獲取用戶的更完整的信息剃执。
OAuth授權(quán)
OAuth 2.0 四種模式
http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html
https://learnku.com/articles/20082
OpenID Connect認(rèn)證
OIDC在OAuth2.0之上增加了ID token包含用戶信息
Session與JWT
Session
1、用戶向服務(wù)器發(fā)送用戶名和密碼懈息。
2肾档、服務(wù)器驗(yàn)證通過(guò)后，在當(dāng)前對(duì)話（session）里面保存相關(guān)數(shù)據(jù)辫继，比如用戶角色怒见、登錄時(shí)間等等。
3姑宽、服務(wù)器向用戶返回一個(gè) session_id遣耍，寫入用戶的 Cookie。
4低千、用戶隨后的每一次請(qǐng)求配阵，都會(huì)通過(guò) Cookie，將 session_id 傳回服務(wù)器示血。
5棋傍、服務(wù)器收到 session_id，找到前期保存的數(shù)據(jù)难审，由此得知用戶的身份瘫拣。
這種模式的問(wèn)題在于，擴(kuò)展性（scaling）不好告喊。單機(jī)當(dāng)然沒(méi)有問(wèn)題麸拄，如果是服務(wù)器集群派昧，或者是跨域的服務(wù)導(dǎo)向架構(gòu)，就要求 session 數(shù)據(jù)共享拢切，每臺(tái)服務(wù)器都能夠讀取 session蒂萎。
舉例來(lái)說(shuō)，A 網(wǎng)站和 B 網(wǎng)站是同一家公司的關(guān)聯(lián)服務(wù)』匆現(xiàn)在要求五慈，用戶只要在其中一個(gè)網(wǎng)站登錄，再訪問(wèn)另一個(gè)網(wǎng)站就會(huì)自動(dòng)登錄主穗，請(qǐng)問(wèn)怎么實(shí)現(xiàn)泻拦？
一種解決方案是 session 數(shù)據(jù)持久化，寫入數(shù)據(jù)庫(kù)或別的持久層忽媒。各種服務(wù)收到請(qǐng)求后争拐，都向持久層請(qǐng)求數(shù)據(jù)。這種方案的優(yōu)點(diǎn)是架構(gòu)清晰晦雨，缺點(diǎn)是工程量比較大架曹。另外，持久層萬(wàn)一掛了金赦，就會(huì)單點(diǎn)失敗音瓷。
另一種方案是服務(wù)器索性不保存 session 數(shù)據(jù)了，所有數(shù)據(jù)都保存在客戶端夹抗，每次請(qǐng)求都發(fā)回服務(wù)器绳慎。JWT 就是這種方案的一個(gè)代表。
JWT
1漠烧、用戶向服務(wù)器發(fā)送用戶名和密碼杏愤。
2、服務(wù)器驗(yàn)證通過(guò)后已脓，返回包含用戶權(quán)限珊楼、過(guò)期時(shí)間的JWT token。
3度液、客戶端每次與服務(wù)器通信厕宗，都要帶上這個(gè) JWT。你可以把它放在 Cookie 里面自動(dòng)發(fā)送堕担，但是這樣不能跨域已慢，所以更好的做法是放在 HTTP 請(qǐng)求的頭信息Authorization字段里面。
4霹购、服務(wù)器完全只靠這個(gè)對(duì)象認(rèn)定用戶身份佑惠。為了防止用戶篡改數(shù)據(jù)，服務(wù)器在生成這個(gè)對(duì)象的時(shí)候，會(huì)加上簽名膜楷。
服務(wù)器就不保存任何 session 數(shù)據(jù)了旭咽，也就是說(shuō)，服務(wù)器變成無(wú)狀態(tài)了赌厅，從而比較容易實(shí)現(xiàn)擴(kuò)展穷绵。
JWT 的三個(gè)部分依次如下。
Header（頭部）
Payload（負(fù)載）
Signature（簽名）
Header包含
- alg屬性表示簽名的算法（algorithm）察蹲，默認(rèn)是 HMAC SHA256（寫成 HS256）
- typ屬性表示這個(gè)令牌（token）的類型（type）请垛，JWT 令牌統(tǒng)一寫為JWT
Payload包含
- iss (issuer)：簽發(fā)人
- exp (expiration time)：過(guò)期時(shí)間
- sub (subject)：主題
- aud (audience)：受眾
- nbf (Not Before)：生效時(shí)間
- iat (Issued At)：簽發(fā)時(shí)間
- jti (JWT ID)：編號(hào)
可以自定義字段
這個(gè) JSON 對(duì)象也要使用 Base64URL 算法轉(zhuǎn)成字符串催训。
Signature簽名
Signature 部分是對(duì)前兩部分的簽名洽议，防止數(shù)據(jù)篡改。
首先漫拭，需要指定一個(gè)密鑰（secret）亚兄。這個(gè)密鑰只有服務(wù)器才知道，不能泄露給用戶采驻。然后审胚，使用 Header 里面指定的簽名算法（默認(rèn)是 HMAC SHA256），按照下面的公式產(chǎn)生簽名礼旅。
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
Spring-Security 學(xué)習(xí)
Spring Security Demo
Video https://www.youtube.com/watch?v=her_7pa0vrg
git@github.com:amigoscode/spring-boot-security-course.git
常用的 Http 認(rèn)證方式
HTTP Basic Authentication
HTTP Basic Authentication 又叫基礎(chǔ)認(rèn)證膳叨，它簡(jiǎn)單地使用 Base64 算法對(duì)用戶名、密碼進(jìn)行加密痘系，并將加密后的信息放在請(qǐng)求頭 Header 中菲嘴，本質(zhì)上還是明文傳輸用戶名、密碼汰翠，并不安全龄坪，所以最好在 Https 環(huán)境下使用。
Form 表單認(rèn)證
Form 表單的認(rèn)證方式并不是HTTP規(guī)范复唤。所以實(shí)現(xiàn)方式也呈現(xiàn)多樣化健田，其實(shí)我們平常的掃碼登錄，手機(jī)驗(yàn)證碼登錄都屬于表單登錄的范疇佛纫。表單認(rèn)證一般都會(huì)配合 Cookie妓局，Session 的使用，現(xiàn)在很多 Web 站點(diǎn)都使用此認(rèn)證方式呈宇。用戶在登錄頁(yè)中填寫用戶名和密碼好爬，服務(wù)端認(rèn)證通過(guò)后會(huì)將 sessionId 返回給瀏覽器端，瀏覽器會(huì)保存 sessionId 到瀏覽器的 Cookie 中攒盈。因?yàn)?HTTP 是無(wú)狀態(tài)的抵拘，所以瀏覽器使用 Cookie 來(lái)保存 sessionId。下次客戶端會(huì)在發(fā)送的請(qǐng)求中會(huì)攜帶 sessionId 值型豁，服務(wù)端發(fā)現(xiàn) sessionId 存在并以此為索引獲取用戶存在服務(wù)端的認(rèn)證信息進(jìn)行認(rèn)證操作僵蛛。認(rèn)證過(guò)則會(huì)提供資源訪問(wèn)尚蝌。
我們?cè)赟pring Security 實(shí)戰(zhàn)干貨：登錄后返回 JWT Token 一文其實(shí)也是通過(guò) Form 提交來(lái)獲取 Jwt 其實(shí) Jwt 跟 sessionId 同樣的作用，只不過(guò) Jwt 天然攜帶了用戶的一些信息充尉，而 sessionId 需要去進(jìn)一步獲取用戶信息飘言。
Json Web Token 的認(rèn)證方式 Bearer Authentication
我們通過(guò)表單認(rèn)證獲取 Json Web Token ，那么如何使用它呢? 通常我們會(huì)把 Jwt 作為令牌使用 Bearer Authentication 方式使用驼侠。Bearer Authentication 是一種基于令牌的 HTTP 身份驗(yàn)證方案姿鸿，用戶向服務(wù)器請(qǐng)求訪問(wèn)受限資源時(shí)，會(huì)攜帶一個(gè) Token 作為憑證倒源，檢驗(yàn)通過(guò)則可以訪問(wèn)特定的資源苛预。最初是在 RFC 6750 中作為 OAuth 2.0 的一部分，但有時(shí)也可以單獨(dú)使用笋熬。我們?cè)谑褂?Bear Token 的方法是在請(qǐng)求頭的 Authorization 字段中放入 Bearer <token> 的格式的加密串(Json Web Token)热某。請(qǐng)注意 Bearer 前綴與 Token 之間有一個(gè)空字符位，與基本身份驗(yàn)證類似胳螟，Bearer Authentication 只能在HTTPS（SSL）上使用昔馋。
