該文章轉載自https://juejin.cn/post/6844904034181070861
原作者ID為：秋天不落葉
原作者發(fā)表時間為：2019年12月29日
以便更好閱讀內(nèi)容細節(jié)經(jīng)過處理

什么是認證（Authentication）

• 通俗地講就是驗證當前用戶的身份，證明 “你是你自己”（比如：每天上下班需要通過指紋打卡，當你的指紋和系統(tǒng)里錄入的指紋相匹配時，則打卡成功）
• 互聯(lián)網(wǎng)中的認證：
  用戶名密碼登錄
  郵箱發(fā)送登錄鏈接
  手機號接收驗證碼
  只要能輸入正確的郵箱鏈接/驗證碼，就可通過認證

什么是授權（Authorization）

• 用戶授予第三方應用訪問該用戶某些資源的權限
  你在安裝使用手機APP時 會詢問是否允許授予權限（訪問相冊、地理位置等權限）
  你在使用微信小程序登錄時會詢問是否允許授予權限（獲取昵稱、頭像、地區(qū)、性別等個人信息）
  實現(xiàn)授權的方式有：cookie、session、token、OAuth

什么是憑證（Credentials）

• 實現(xiàn)認證和授權的前提是需要一種媒介（證書） 來標記訪問者的身份
  在戰(zhàn)國時期，商鞅變法發(fā)明了照身帖。照身帖是官府發(fā)放的一塊打磨光滑細密的竹板，上面刻有持有人的頭像和籍貫信息。若沒有的話會被認為是黑戶，或者間諜之類的。
  在現(xiàn)實生活中，每個人都會有一張專屬的居民身份證是用于證明持有人身份的一種法定證件，通過身份證，我們可以辦理手機卡/銀行卡/個人貸款/交通出行等等，這就是憑證
  在互聯(lián)網(wǎng)應用中，一般網(wǎng)站（如掘金）會有兩種模式，游客模式和登錄模式。游客模式下，可以正常瀏覽網(wǎng)站上面的文章，但如果想要點贊/收藏/分享文章，就需要登錄或者注冊賬號。當用戶登錄成功后，服務器會給該用戶使用的瀏覽器頒發(fā)一個令牌（token），這個令牌用來表明用戶的身份，每次瀏覽器發(fā)送請求時都會帶上這個令牌，就可以使用游客模式下無法使用的功能

什么是 Cookie

HTTP 是無狀態(tài)的協(xié)議（對于事務處理沒有記憶能力，每次客戶端和服務端會話完成時，服務端不會保存任何會話信息）：每個請求都是完全獨立的，服務端無法確認當前訪問者的身份信息，無法分辨上一次的請求發(fā)送者和這一次的發(fā)送者是不是同一個人。所以服務器與瀏覽器為了進行會話跟蹤（知道是誰在訪問我），就必須主動的去維護一個狀態(tài)，這個狀態(tài)用于告知服務端前后兩個請求是否來自同一瀏覽器。而這個狀態(tài)需要通過 cookie 或者 session 去實現(xiàn)
cookie 存儲在客戶端： cookie 是服務器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會在瀏覽器下次向同一服務器再發(fā)起請求時被攜帶并發(fā)送到服務器上
cookie 是不可跨域的： 每個 cookie 都會綁定單一的域名，無法在別的域名下獲取使用，但一級域名和二級域名之間允許共享使用（靠的是 domain）

cookie的屬性

• name=value 【鍵值對，設置 Cookie 的名稱及相對應的值，兩者都必須為字符串類型，如果值為 Unicode 字符，需要為字符編碼。如果值為二進制數(shù)據(jù)，需要使用 BASE64 編碼】
• domain 【指定 cookie 所屬域名，默認是當前域名】
• path 【指定 cookie 在哪個路徑（路由）下生效，默認是 '/'。如果設置為 /abc，則只有 /abc 下的路由可以訪問到該 cookie，如：/abc/read】
• maxAge 【cookie 失效的時間，單位秒。如果為整數(shù)，則該 cookie 在 maxAge 秒后失效。如果為負數(shù)，該 cookie 為臨時 cookie ，關閉瀏覽器即失效，瀏覽器也不會以任何形式保存該 cookie 。如果為 0，表示刪除該 cookie 。默認為 -1】
• expires 【過期時間，在設置的某個時間點后該 cookie 就會失效。一般瀏覽器的 cookie 都是默認儲存的，當關閉瀏覽器結束這個會話的時候，這個 cookie 也就會被刪除】
• secure 【該 cookie 是否僅被使用安全協(xié)議傳輸。安全協(xié)議有 HTTPS，SSL等，在網(wǎng)絡上傳輸數(shù)據(jù)之前先將數(shù)據(jù)加密。默認為false。當 secure 值為 true 時，cookie 在 HTTP 中是無效，在 HTTPS 中才有效】
• httpOnly 【如果給某個 cookie 設置了 httpOnly 屬性，則無法通過 JS 腳本讀取到該 cookie 的信息，但還是能通過瀏覽器的Application功能手動修改 cookie】

什么是 Session

• session 是另一種記錄服務器和客戶端會話狀態(tài)的機制
• session 是基于 cookie 實現(xiàn)的，session 存儲在服務器端，sessionId 會被存儲到客戶端的cookie 中

Session示意圖.png

• Session 認證流程：
  1. 用戶第一次請求服務器的時候，服務器根據(jù)用戶提交的相關信息，創(chuàng)建對應的 Session
  2. 請求返回時將此 Session 的唯一標識信息 SessionID 返回給瀏覽器
  3. 瀏覽器接收到服務器返回的 SessionID 信息后，會將此信息存入到 Cookie 中，同時 Cookie 記錄此 SessionID 屬于哪個域名
  4. 當用戶第二次訪問服務器的時候，請求會自動判斷此域名下是否存在 Cookie 信息，如果存在自動將 Cookie 信息也發(fā)送給服務端，服務端會從 Cookie 中獲取 SessionID，再根據(jù) SessionID 查找對應的 Session 信息，如果沒有找到說明用戶沒有登錄或者登錄失效，如果找到 Session 證明用戶已經(jīng)登錄可執(zhí)行后面操作。

根據(jù)以上流程可知，SessionID 是連接 Cookie 和 Session 的一道橋梁，大部分系統(tǒng)也是根據(jù)此原理來驗證用戶登錄狀態(tài)。

Cookie 和 Session 的區(qū)別

• 安全性： Session 比 Cookie 安全，Session 是存儲在服務器端的，Cookie 是存儲在客戶端的
• 存取值的類型不同：Cookie 只支持存字符串數(shù)據(jù)，想要設置其他類型的數(shù)據(jù)，需要將其轉換成字符串，Session 可以存任意數(shù)據(jù)類型
• 有效期不同： Cookie 可設置為長時間保持，比如我們經(jīng)常使用的默認登錄功能，Session 一般失效時間較短，客戶端關閉（默認情況下）或者 Session 超時都會失效
• 存儲大小不同： 單個 Cookie 保存的數(shù)據(jù)不能超過 4K，Session 可存儲數(shù)據(jù)遠高于 Cookie，但是當訪問量過多，會占用過多的服務器資源

什么是 Token（令牌）

Access Token是指訪問資源接口（API）時所需要的資源憑證
Token的組成由：uid(用戶唯一的身份標識)、time(當前時間的時間戳)、sign（簽名，token 的前幾位以哈希算法壓縮成的一定長度的十六進制字符串）
Token的特點：服務端無狀態(tài)化、可擴展性好、支持移動端設備、支持跨程序調(diào)用、安全

Token示意圖.png

• Token的身份驗證流程為
  1. 客戶端使用用戶名跟密碼請求登錄
  2. 服務端收到請求，去驗證用戶名與密碼
  3. 驗證成功后，服務端會簽發(fā)一個 Access Token 并把這個 Access Token 發(fā)送給客戶端
  4. 客戶端收到 Access Token 以后，會把它存儲起來，比如放在 Cookie 里或者 本地文件 里
  5. 客戶端每次向服務端請求資源的時候需要帶著服務端簽發(fā)的 Access Token
  6. 服務端收到請求，然后去驗證客戶端請求里面帶著的 Access Token ，如果驗證成功，就向客戶端返回請求的數(shù)據(jù)
• Access Token的特點
  1. 每一次請求都需要攜帶 Access Token，需要把 Access Token 放到 HTTP 的 Header 里
  2. 基于 Access Token 的用戶認證是一種服務端無狀態(tài)的認證方式，服務端不用存放 Access Token 數(shù)據(jù)。用解析 Access Token 的計算時間換取 Session 的存儲空間，從而減輕服務器的存儲壓力，減少服務器頻繁查詢數(shù)據(jù)庫的計算壓力
  3. Access Token 完全由應用管理，所以它可以避開同源策略

什么是Refresh Token

Refresh Token是另一種Token的實現(xiàn)形式，是專門用于刷新 Access Token 的 Token。如果沒有 Refresh Token每次 Access Token 刷新都要用戶輸入用戶名與密碼。有了 Refresh Token，可以減少這個麻煩，客戶端直接用 Refresh Token 去更新 Access Token，無需用戶進行額外的操作

Refresh Token示意圖.png

• Refresh Token的特點
  1. Access Token 的有效期比較短，當 Access Token 由于過期而失效時，使用 Refresh Token 就可以獲取到新的 Token，如果 Refresh Token 也失效了，用戶就只能重新登錄
  2. Refresh Token 及過期時間是存儲在服務器的數(shù)據(jù)庫中，只有在申請新的 Access Token 時才會驗證，不會對業(yè)務接口響應時間造成影響，也不需要向 Session 一樣一直保持在內(nèi)存中以應對大量的請求

Token 和 Session 的區(qū)別

• Session 是一種記錄服務器和客戶端會話狀態(tài)的機制，使服務端有狀態(tài)化，可以記錄會話信息。而 Token 是令牌，訪問資源接口（API）時所需要的資源憑證。Token 使服務端無狀態(tài)化，不會存儲會話信息
• Session 和 Token 并不矛盾，作為身份認證 Token 安全性比 Session 好，因為每一個請求都有簽名還能防止監(jiān)聽以及重放攻擊，而 Session 就必須依賴鏈路層來保障通訊安全了。如果你需要實現(xiàn)有狀態(tài)的會話，仍然可以增加 Session 來在服務器端保存一些狀態(tài)
• 所謂 Session 認證只是簡單的把 User 信息存儲到 Session 里，因為 SessionID 的不可預測性，暫且認為是安全的。而 Token ，如果指的是 OAuth Token 或類似的機制的話，提供的是 認證 和 授權 ，認證是針對用戶，授權是針對 App 。其目的是讓某 App 有權利訪問某用戶的信息。這里的 Token 是唯一的。不可以轉移到其它 App上，也不可以轉到其它用戶上。Session 只提供一種簡單的認證，即只要有此 SessionID ，即認為有此 User 的全部權利。是需要嚴格保密的，這個數(shù)據(jù)應該只保存在站方，不應該共享給其它網(wǎng)站或者第三方 App。所以簡單來說：如果你的用戶數(shù)據(jù)可能需要和第三方共享，或者允許第三方調(diào)用 API 接口，用 Token

什么是 JWT

JSON Web Token（簡稱 JWT）是一種認證授權機制是目前最流行的跨域認證解決方案，JWT 是為了在網(wǎng)絡應用環(huán)境間傳遞聲明而執(zhí)行的一種基于 JSON 的開放標準。JWT 的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便于從資源服務器獲取資源。比如用在用戶登錄上，因為JWT 可以使用 HMAC 算法或者是 RSA 的公/私秘鑰進行簽名。所以經(jīng)過JWT加密后傳遞的信息是可信的

原作者推薦JWT教程老師：阮一峰

鏈接：http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html

JWT示意圖.png

• JWT認證流程
  1. 用戶輸入用戶名/密碼登錄，服務端認證成功后，會返回給客戶端一個 JWT
  2. 客戶端將 Access Token 保存到本地（通常使用 本地文件，也可以使用 cookie）
  3. 當用戶希望訪問一個受保護的路由或者資源的時候，需要請求頭的 Authorization 字段中使用Bearer 模式添加 JWT：Authorization: Bearer <Token>
• JWT的特點
  1. 服務端的保護路由將會檢查請求頭 Authorization 中的 JWT 信息，如果合法，則允許用戶的行為
  2. JWT 是自包含的（內(nèi)部包含了一些會話信息），因此減少了服務器需要查詢數(shù)據(jù)庫的需要
  3. JWT 并不使用 Cookie 的，所以可以使用任何域名提供的 API 服務而不需要擔心跨域資源共享問題（CORS）
  4. 用戶的狀態(tài)不存儲在服務端的內(nèi)存中，所以這是一種無狀態(tài)的認證機制
• JWT的使用方式
  1. 添加到header中：
     GET /calendar/v1/events
     Host: api.example.com
     Authorization: Bearer <token>
  2. 添加到post請求中：requests.post(url,headers=header,data=tokenData)
  3. 添加到鏈接中：https:url/user?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Token 和 JWT 的聯(lián)系和區(qū)別

• 聯(lián)系
  1. 都是訪問資源的令牌
  2. 都可以記錄用戶的信息
  3. 都是使服務端無狀態(tài)化
  4. 都是只有驗證成功后，客戶端才能訪問服務端上受保護的資源
• 區(qū)別
  1. Token：服務端驗證客戶端發(fā)送過來的 Token 時，還需要查詢數(shù)據(jù)庫獲取用戶信息，然后驗證 Token 是否有效
  2. JWT： 將 Token 和 Payload 加密后存儲于客戶端，服務端只需要使用密鑰解密進行校驗（校驗也是 JWT 自己實現(xiàn)的）即可，不需要查詢或者減少查詢數(shù)據(jù)庫，因為 JWT 自包含了用戶信息和加密的數(shù)據(jù)

常見的前后端鑒權方式

• Session-Cookie
• Token 驗證（包括 JWT，SSO）
• OAuth2.0（開放授權）

常見的哈希加密算法

哈希算法家族示意圖.png

哈希算法又稱散列算法、散列函數(shù)、哈希函數(shù)，是一種從任何一種數(shù)據(jù)中創(chuàng)建小的數(shù)字“指紋”的方法。哈希算法將數(shù)據(jù)重新打亂混合，重新創(chuàng)建一個哈希值，哈希算法主要用來保障數(shù)據(jù)真實性(即完整性)，即發(fā)信人將原始消息和哈希值一起發(fā)送，收信人通過相同的哈希函數(shù)來校驗原始數(shù)據(jù)是否真實

• 哈希算法的特點
  1. 正向快速：原始數(shù)據(jù)可以快速計算出哈希值
  2. 逆向困難：通過哈希值基本不可能推導出原始數(shù)據(jù)
  3. 輸入敏感：原始數(shù)據(jù)只要有一點變動，得到的哈希值差別很大
  4. 沖突避免：很難找到不同的原始數(shù)據(jù)得到相同的哈希值，宇宙中原子數(shù)大約在 10 的 60 次方到 80 次方之間，所以 2 的 256 次方有足夠的空間容納所有的可能，算法好的情況下沖突碰撞的概率很低

常見問題

• 使用 Cookie 時需要考慮的問題
  1. 存儲在客戶端，容易被客戶端篡改，使用前需要驗證合法性
  2. 不要存儲敏感數(shù)據(jù)，比如用戶密碼，賬戶余額
  3. 使用 httpOnly 可以在一定程度上提高安全性
  4. 盡量減少 Cookie 的體積，能存儲的數(shù)據(jù)量不能超過 4kb
  5. 設置正確的 domain 和 path，減少數(shù)據(jù)傳輸
  6. Cookie 無法跨域
  7. 一個瀏覽器針對一個網(wǎng)站最多存 20 個Cookie，瀏覽器一般只允許存放 300 個Cookie
  8. 移動端對 Cookie 的支持不是很好，而 Session 需要基于 Cookie 實現(xiàn)，所以移動端常用的是 Token
• 使用 Session 時需要考慮的問題
  1. Session 存儲在服務器里面，當用戶同時在線量比較多時，這些 Session 會占據(jù)較多的內(nèi)存，需要在服務端定期的去清理過期的 Session
  2. 當網(wǎng)站采用集群部署的時候，會遇到多臺 web 服務器之間如何做 Session 共享的問題。因為 Session 是由單個服務器創(chuàng)建的，但是處理用戶請求的服務器不一定是那個創(chuàng)建 Session 的服務器，那么該服務器就無法拿到之前已經(jīng)放入到 Session 中的登錄憑證之類的信息
  3. 當多個應用要共享 Session 時，除了以上問題，還會遇到跨域問題，因為不同的應用可能部署的主機不一樣，需要在各個應用做好 Cookie 跨域的處理
  4. SessionId 是存儲在 cookie 中的，假如瀏覽器禁止 Cookie 或不支持 Cookie 怎么辦？ 一般會把 SessionId 跟在 url 參數(shù)后面即重寫 url，所以 Session 不一定非得需要靠 Cookie 實現(xiàn)
  5. 關閉瀏覽器并不會導致Session丟失，除非通知服務器刪除Session，但當使用會話 Cookie 來保存 SessionId時，關閉瀏覽器后雖然這個 SessionId 消失并且再次連接服務器時也就無法找到原來的 Session，但并不意味著服務器上的Session就會一并刪除，這一意味著迫使服務器要為 Session 設置了一個失效時間，否則已經(jīng)過期的無效的Session會越積越多
• 使用 Token 時需要考慮的問題
  1. 如果用數(shù)據(jù)庫來存儲 Token 會導致查詢時間太長，可以選擇放在內(nèi)存當中。比如 redis 很適合對 Token 查詢的需求
  2. Token 完全由應用管理，所以它可以避開同源策略
  3. Token 可以避免 CSRF 攻擊(因為不需要 cookie )
• 使用 JWT 時需要考慮的問題
  1. JWT 并不依賴 Cookie ，所以可以使用任何域名提供你的 API 服務而不需要擔心跨域資源共享問題（CORS）
  2. JWT 默認是不加密，但也是可以加密的。生成原始 Token 以后，可以用密鑰再加密一次
  3. JWT 不加密的情況下，不能將秘密數(shù)據(jù)寫入 JWT
  4. JWT 不僅可以用于認證，也可以用于交換信息。有效使用 JWT，可以降低服務器查詢數(shù)據(jù)庫的次數(shù)
  5. JWT 最大的優(yōu)勢是服務器不再需要存儲 Session，使得服務器認證鑒權業(yè)務可以方便擴展。但這也是 JWT 最大的缺點：由于服務器不需要存儲 Session 狀態(tài)，因此使用過程中無法廢棄某個 Token 或者更改 Token 的權限。也就是說一旦 JWT 簽發(fā)了，到期之前就會始終有效，除非服務器部署額外的邏輯
  6. JWT 本身包含了認證信息，一旦泄露，任何人都可以獲得該令牌的所有權限。為了減少盜用，JWT的有效期應該設置得比較短。對于一些比較重要的權限，使用時應該再次對用戶進行認證
  7. JWT 適合一次性的命令認證，頒發(fā)一個有效期極短的 JWT，即使暴露了危險也很小，由于每次操作都會生成新的 JWT，因此也沒必要保存 JWT，真正實現(xiàn)無狀態(tài)
  8. 為了減少盜用，JWT 不應該使用 HTTP 協(xié)議明碼傳輸，要使用 HTTPS 協(xié)議傳輸
• 使用加密算法時需要考慮的問題
  1. 絕不要以明文存儲密碼
  2. 永遠使用 哈希算法 來處理密碼，絕不要使用 Base64 或其他編碼方式來存儲密碼，這和以明文存儲密碼是一樣的，使用哈希，而不要使用編碼。編碼以及加密，都是雙向的過程，而密碼是保密的，應該只被它的所有者知道， 這個過程必須是單向的。哈希正是用于做這個的，從來沒有解哈希這種說法， 但是編碼就存在解碼，加密就存在解密
  3. 絕不要使用弱哈?；蛞驯黄平獾墓Ｋ惴ǎ?MD5 或 SHA1 ，只使用強密碼哈希算法
  4. 絕不要以明文形式顯示或發(fā)送密碼，即使是對密碼的所有者也應該這樣。如果需要 “忘記密碼” 的功能，可以隨機生成一個新的 一次性的（這點很重要）密碼，然后把這個密碼發(fā)送給用戶

其他附帶問題

• 分布式架構下 Session 共享方案
  1. Session 復制，任何一個服務器上的 Session 發(fā)生改變（增刪改），該節(jié)點會把這個 Session 的所有內(nèi)容序列化，然后廣播給所有其它節(jié)點，不管其他服務器需不需要 Session ，以此來保證 Session 同步
     特點：可容錯，各個服務器間 Session 能夠?qū)崟r響應
     缺點：會對網(wǎng)絡負荷造成一定壓力，如果 Session 量大的話可能會造成網(wǎng)絡堵塞，拖慢服務器性能
  2. 粘性 Session /IP 綁定策略，采用 Ngnix 中的 ip_hash 機制，將某個 ip的所有請求都定向到同一臺服務器上，即將用戶與服務器綁定。 用戶第一次請求時，負載均衡器將用戶的請求轉發(fā)到了 A 服務器上，如果負載均衡器設置了粘性 Session 的話，那么用戶以后的每次請求都會轉發(fā)到 A 服務器上，相當于把用戶和 A 服務器粘到了一塊，這就是粘性 Session 機制
     優(yōu)點：簡單，不需要對 Session 做任何處理
     缺點：缺乏容錯性，如果當前訪問的服務器發(fā)生故障，用戶被轉移到第二個服務器上時，他的 Session 信息都將失效
     適用場景：發(fā)生故障對客戶產(chǎn)生的影響較??；服務器發(fā)生故障是低概率事件
     實現(xiàn)方式：以 Nginx 為例，在 upstream 模塊配置 ip_hash 屬性即可實現(xiàn)粘性 Session
  3. Session共享（常用），使用分布式緩存方案比如 Memcached 、Redis 來緩存 session，但是要求 Memcached 或 Redis 必須是集群，把 Session 放到 Redis 中存儲，雖然架構上變得復雜，并且需要多訪問一次 Redis，但可以帶來Session 共享、可以水平擴展（增加 Redis 服務器）、服務器重啟 Session 不丟失（不過也要注意 Session 在 Redis 中的刷新/失效機制）、不僅可以跨服務器 Session 共享，甚至可以跨平臺（例如網(wǎng)頁端和 APP 端）
  4. Session持久化，將 Session 存儲到數(shù)據(jù)庫中，保證 Session 的持久化
     優(yōu)點：服務器出現(xiàn)問題，Session 不會丟失
     缺點：如果網(wǎng)站的訪問量很大，把 Session 存儲到數(shù)據(jù)庫中，會對數(shù)據(jù)庫造成很大壓力，還需要增加額外的開銷維護數(shù)據(jù)庫