先後端接口鑑權全解 Cookie/Session/Token 的區別

時間  2021-03-07
標籤 javascript html 前端 java node ios git github web 面試 欄目 HTML 简体版
原文   原文鏈接

原文連接：先後端接口鑑權全解javascript

不知不覺也寫得比較長了，一次看不完建議收藏夾！本文主要解釋與請求狀態相關的術語（cookie、session、token）和幾種常見登陸的實現方式，但願你們看完本文後能夠有比較清晰的理解，有感到迷惑的地方請在評論區提出。html

Cookie

衆所周知，http 是無狀態協議，瀏覽器和服務器不可能憑協議的實現辨別請求的上下文。前端

因而 cookie 登場，既然協議自己不能分辨連接，那就在請求頭部手動帶着上下文信息吧。java

舉個例子，之前去旅遊的時候，到了景區可能會須要存放行李，被大包小包壓着，旅遊也不開心啦。在存放行李後，服務員會給你一個牌子，上面寫着你的行李放在哪一個格子，離開時，你就能憑這個牌子和上面的數字成功取回行李。node

cookie 作的正是這麼一件事，旅客就像客戶端，寄存處就像服務器，憑着寫着數字的牌子，寄存處（服務器）就能分辨出不一樣旅客（客戶端）。ios

你會不會想到，若是牌子被偷了怎麼辦，cookie 也會被偷嗎？確實會，這就是一個很常被提到的網絡安全問題——CSRF。能夠在這篇文章瞭解關於 CSRF 的成因和應對方法。git

cookie 誕生初彷佛是用於電商存放用戶購物車一類的數據，但如今前端擁有兩個 storage（local、session），兩種數據庫（websql、IndexedDB），根本不愁信息存放問題，因此如今基本上 100% 都是在鏈接上證實客戶端的身份。例如登陸以後，服務器給你一個標誌，就存在 cookie 裏，以後再鏈接時，都會自動帶上 cookie，服務器便分清誰是誰。另外，cookie 還能夠用於跟蹤一個用戶，這就產生了隱私問題，因而也就有了「禁用 cookie」這個選項（然而如今這個時代禁用 cookie 是挺麻煩的事情）。github

設置方式

現實世界的例子明白了，在計算機中怎麼才能設置 cookie 呢？通常來講，安全起見，cookie 都是依靠 set-cookie 頭設置，且不容許 JavaScript 設置。web

Set-Cookie: <cookie-name>=<cookie-value>
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
Set-Cookie: <cookie-name>=<cookie-value>; Secure
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly

Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None; Secure

// Multiple attributes are also possible, for example:
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

其中 <cookie-name>=<cookie-value> 這樣的 kv 對，內容隨你定，另外還有 HttpOnly、SameSite 等配置，一條 Set-Cookie 只配置一項 cookie。面試

  • Expires 設置 cookie 的過時時間（時間戳），這個時間是客戶端時間。
  • Max-Age 設置 cookie 的保留時長（秒數），同時存在 Expires 和 Max-Age 的話，Max-Age 優先
  • Domain 設置生效的域名，默認就是當前域名，不包含子域名
  • Path 設置生效路徑，/ 全匹配
  • Secure 設置 cookie 只在 https 下發送，防止中間人攻擊
  • HttpOnly 設置禁止 JavaScript 訪問 cookie，防止XSS
  • SameSite 設置跨域時不攜帶 cookie，防止CSRF

Secure 和 HttpOnly 是強烈建議開啓的。SameSite 選項須要根據實際狀況討論，由於 SameSite 可能會致使即便你用 CORS 解決了跨越問題，依然會由於請求沒自帶 cookie 引發一系列問題，一開始還覺得是 axios 配置問題，繞了一大圈，然而根本不要緊。

其實由於 Chrome 在某一次更新後把沒設置 SameSite 默認爲 Lax，你不在服務器手動把 SameSite 設置爲 None 就不會自動帶 cookie 了。

發送方式

參考 MDN，cookie 的發送格式以下（其中 PHPSESSID 相關內容下面會提到）：

Cookie: <cookie-list>
Cookie: name=value
Cookie: name=value; name2=value2; name3=value3

Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1

在發送 cookie 時，並不會傳上面提到的配置到服務器，由於服務器在設置後就不須要關心這些信息了，只要現代瀏覽器運做正常，收到的 cookie 就是沒問題的。

Session

從 cookie 說到 session，是由於 session 纔是真正的「信息」，如上面提到的，cookie 是容器，裏面裝着 PHPSESSID=298zf09hf012fh2;，這就是一個 session ID。

不知道 session 和 session id 會不會讓你看得有點頭暈？

當初 session 的存在就是要爲客戶端和服務器鏈接提供的信息，因此我將 session 理解爲信息，而 session id 是獲取信息的鑰匙，一般是一串惟一的哈希碼。

接下來分析兩個 node.js express 的中間件，理解兩種 session 的實現方式。

session 信息能夠儲存在客戶端，如 cookie-session，也能夠儲存在服務器，如 express-session。使用 session ID 就是把 session 放在服務器裏，用 cookie 裏的 id 尋找服務器的信息。

客戶端儲存

對於 cookie-session 庫，比較容易理解，其實就是把全部信息加密後塞到 cookie 裏。其中涉及到 cookies 庫。在設置 session 時其實就是調用 cookies.set，把信息寫到 set-cookie 裏，再返回瀏覽器。換言之，取值和賦值的本質都是操做 cookie。

瀏覽器在接收到 set-cookie 頭後，會把信息寫到 cookie 裏。在下次發送請求時，信息又經過 cookie 原樣帶回來，因此服務器什麼東西都不用存，只負責獲取和處理 cookie 裏的信息，這種實現方法不須要 session ID。

這是一段使用 cookie-session 中間件爲請求添加 cookie 的代碼：

const express = require('express')
var cookieSession = require('cookie-session')
const app = express()
app.use(
  cookieSession({
    name: 'session',
    keys: [
      /* secret keys */
      'key',
    ],
    // Cookie Options
    maxAge: 24 * 60 * 60 * 1000, // 24 hours
  })
)
app.get('/', function(req, res) {
  req.session.test = 'hey'
  res.json({
    wow: 'crazy',
  })
})

app.listen(3001)

在經過 app.use(cookieSession()) 使用中間件以前，請求是不會設置 cookie 的，添加後再訪問（而且在設置 req.session 後，若不添加 session 信息就不必寫、也沒內容寫到 cookie 裏），就能看到服務器響應頭部新增了下面兩行，分別寫入 session 和 session.sig：

Set-Cookie: session=eyJ0ZXN0IjoiaGV5In0=; path=/; expires=Tue, 23 Feb 2021 01:07:05 GMT; httponly
Set-Cookie: session.sig=QBoXofGvnXbVoA8dDmfD-GMMM6E; path=/; expires=Tue, 23 Feb 2021 01:07:05 GMT; httponly

而後你就能在 DevTools 的 Application 標籤看到 cookie 成功寫入。session 的值 eyJ0ZXN0IjoiaGV5In0= 經過 base64 解碼（不瞭解 base64 的話能夠看這裏）便可獲得 {"test":"hey"}，這就是所謂的「將 session 信息放到客戶端」，由於 base64 編碼並非加密，這就跟明文傳輸沒啥區別，因此請不要在客戶端 session 裏放用戶密碼之類的機密信息。

即便現代瀏覽器和服務器作了一些約定，例如使用 https、跨域限制、還有上面提到 cookie 的 httponly 和 sameSite 配置等，保障了 cookie 安全。可是想一想，傳輸安全保障了，若是有人偷看你電腦裏的 cookie，密碼又剛好存在 cookie，那就能無聲無息地偷走密碼。相反的，只放其餘信息或是僅僅證實「已登陸」標誌的話，只要退出一次，這個 cookie 就失效了，算是下降了潛在危險。

說回第二個值 session.sig，它是一個 27 字節的 SHA1 簽名，用以校驗 session 是否被篡改，是 cookie 安全的又一層保障。

服務器儲存

既然要儲存在服務器，那麼 express-session 就須要一個容器 store，它能夠是內存、redis、mongoDB 等等等等，內存應該是最快的，可是重啓程序就沒了，redis 能夠做爲備選，用數據庫存 session 的場景感受很少。

express-session 的源碼沒 cookie-session 那麼簡明易懂，裏面有一個有點繞的問題，req.session 究竟是怎麼插入的？

不關注實現能夠跳過這段，有興趣的話能夠跟着思路看看 express-session 的源碼。

咱們能夠從 .session = 這個關鍵詞開始找，找到：

  • store.generate 否決這個，容易看出這個是初始化使用的
  • Store.prototype.createSession 這個是根據 req 和 sess 參數在 req 中設置 session 屬性，沒錯，就是你了

因而全局搜索 createSession，鎖定 index 裏的 inflate （就是填充的意思）函數。

最後尋找 inflate 的調用點，是使用 sessionID 爲參數的 store.get 的回調函數，一切說得通啦——

在監測到客戶端送來的 cookie 以後，能夠從 cookie 獲取 sessionID，再使用 id 在 store 中獲取 session 信息，掛到 req.session，通過這個中間件，你就能順利地使用 req 中的 session。

那賦值怎麼辦呢？這就和上面儲存在客戶端不一樣了，上面要修改客戶端 cookie 信息，可是對於儲存在服務器的狀況，你修改了 session 那就是「實實在在地修改」了嘛，不用其餘花裏胡哨的方法，內存中的信息就是修改了，下次獲取內存裏的對應信息也是修改後的信息。（僅限於內存的實現方式，使用數據庫時仍須要額外的寫入）

在請求沒有 session id 的狀況下，經過 store.generate 建立新的 session，在你寫 session 的時候，cookie 能夠不改變，只要根據原來的 cookie 訪問內存裏的 session 信息就能夠了。

var express = require('express')
var parseurl = require('parseurl')
var session = require('express-session')

var app = express()

app.use(
  session({
    secret: 'keyboard cat',
    resave: false,
    saveUninitialized: true,
  })
)

app.use(function(req, res, next) {
  if (!req.session.views) {
    req.session.views = {}
  }

  // get the url pathname
  var pathname = parseurl(req).pathname

  // count the views
  req.session.views[pathname] = (req.session.views[pathname] || 0) + 1

  next()
})

app.get('/foo', function(req, res, next) {
  res.json({
    session: req.session,
  })
})

app.get('/bar', function(req, res, next) {
  res.send('you viewed this page ' + req.session.views['/bar'] + ' times')
})

app.listen(3001)

兩種儲存方式的對比

首先仍是計算機世界最重要的哲學問題：時間和空間的抉擇。

儲存在客戶端的狀況，解放了服務器存放 session 的內存，可是每次都帶上一堆 base64 處理的 session 信息，若是量大的話傳輸就會很緩慢。

儲存在服務器相反，用服務器的內存拯救了帶寬。

另外，在退出登陸的實現和結果，也是有區別的。

儲存在服務器的狀況就很簡單，若是 req.session.isLogin = true 是登陸，那麼 req.session.isLogin = false 就是退出。

可是狀態存放在客戶端要作到真正的「即時退出登陸」就很困難了。你能夠在 session 信息里加上過時日期，也能夠直接依靠 cookie 的過時日期，過時以後，就當是退出了。

可是若是你不想等到 session 過時，如今就想退出登陸！怎麼辦？認真想一想你會發現，僅僅依靠客戶端儲存的 session 信息真的沒有辦法作到。

即便你經過 req.session = null 刪掉客戶端 cookie，那也只是刪掉了，可是若是有人曾經把 cookie 複製出來了，那他手上的 cookie 直到 session 信息裏的過時時間前，都是有效的。

說「即時退出登陸」有點標題黨的意味，其實我想表達的是，你沒辦法當即廢除一個 session，這可能會形成一些隱患。

Token

session 說完了，那麼出現頻率超高的關鍵字 token 又是什麼？

不妨谷歌搜一下 token 這個詞，能夠看到冒出來幾個（年紀大的人）比較熟悉的圖片：密碼器。過去網上銀行不是隻要短信認證就能轉帳，還要通過一個密碼器，上面顯示着一個變更的密碼，在轉帳時你須要輸入密碼器中的代碼才能轉帳，這就是 token 現實世界中的例子。憑藉一串碼或是一個數字證實本身身份，這事情不就和上面提到的行李問題仍是同樣的嗎……

其實本質上 token 的功能就是和 session id 如出一轍。你把 session id 說成 session token 也沒什麼問題（Wikipedia 裏就寫了這個別名）。

其中的區別在於，session id 通常存在 cookie 裏，自動帶上；token 通常是要你主動放在請求中，例如設置請求頭的 Authorization 爲 bearer:<access_token>。

然而上面說的都是通常狀況，根本沒有明確規定！

劇透一下，下面要講的 JWT（JSON Web Token）！他是一個 token！可是裏面放着 session 信息！放在客戶端，而且能夠隨你選擇放在 cookie 或是手動添加在 Authorization！可是他就叫 token！

我的以爲你不能經過存放的位置判斷是 token 或是 session id，也不能經過內容判斷是 token 或是 session 信息，session、session id 以及 token 都是很意識流的東西，只要你明白他是什麼、怎麼用就行了，怎麼稱呼不過重要。

另外在搜索資料時也看到有些文章說 session 和 token 的區別就是新舊技術的區別，好像有點道理。

在 session 的 Wikipedia 頁面上 HTTP session token 這一欄，舉例都是 JSESSIONID (JSP)、PHPSESSID (PHP)、CGISESSID (CGI)、ASPSESSIONID (ASP) 等比較傳統的技術，就像 SESSIONID 是他們的代名詞通常；而在研究如今各類平臺的 API 接口和 OAuth2.0 登陸時，都是使用 access token 這樣的字眼，這個區別着實有點意思。

理解 session 和 token 的聯繫以後，能夠在哪裏能看到「活的」 token 呢？

打開 GitHub 進入設置，找到 Settings / Developer settings，能夠看到 Personal access tokens 選項，生成新的 token 後，你就能夠帶着它經過 GitHub API，證實「你就是你」。

在 OAuth 系統中也使用了 Access token 這個關鍵詞，寫過微信登陸的朋友應該都能感覺到 token 是個什麼啦。

Token 在權限證實上真的很重要，不可泄漏，誰拿到 token，誰就是「主人」。因此要作一個 Token 系統，刷新或刪除 Token 是必需要的，這樣在儘快彌補 token 泄漏的問題。

在理解了三個關鍵字和兩種儲存方式以後，下面咱們正式開始說「用戶登陸」相關的知識和兩種登陸規範——JWT 和 OAuth2.0。

接着你可能會頻繁見到 Authentication 和 Authorization 這兩個單詞，它們都是 Auth 開頭，但可不是一個意思，簡單來講前者是驗證，後者是受權。在編寫登陸系統時，要先驗證用戶身份，設置登陸狀態，給用戶發送 token 就是受權。

JWT

全稱 JSON Web Token（RFC 7519），是的，JWT 就是一個 token。爲了方便理解，提早告訴你們，JWT 用的是上面客戶端儲存的方式，因此這部分可能會常常用到上面提到的名稱。

結構

雖然說 JWT 就是客戶端儲存 session 信息的一種，可是 JWT 有着本身的結構：Header.Payload.Signature（分爲三個部分，用 . 隔開）

Header

{
  "alg": "HS256",
  "typ": "JWT"
}

typ 說明 token 類型是 JWT，alg 表明簽名算法，HMAC、SHA25六、RSA 等。而後將其 base64 編碼。

Payload

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

Payload 是放置 session 信息的位置，最後也要將這些信息進行 base64 編碼，結果就和上面客戶端儲存的 session 信息差很少。

不過 JWT 有一些約定好的屬性，被稱爲 Registered claims，包括：

  • iss (issuer)：簽發人
  • exp (expiration time)：過時時間
  • sub (subject)：主題
  • aud (audience)：受衆
  • nbf (Not Before)：生效時間
  • iat (Issued At)：簽發時間
  • jti (JWT ID)：編號

Signature

最後一部分是簽名，和上面提到的 session.sig 同樣是用於防止篡改，不過 JWT 把簽名和內容組合到一塊兒罷了。

JWT 簽名的生成算法是這樣的：

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

使用 Header 裏 alg 的算法和本身設定的密鑰 secret 編碼 base64UrlEncode(header) + "." + base64UrlEncode(payload)

最後將三部分經過 . 組合在一塊兒，你能夠經過 jwt.io Debugger 形象地看到 JWT 的組成原理：

如何使用

在驗證用戶，順利登陸後，會給用戶返回 JWT。由於 JWT 的信息沒有加密，因此別往裏面放密碼，詳細緣由在客戶端儲存的 cookie 中提到。

用戶訪問須要受權的鏈接時，能夠把 token 放在 cookie，也能夠在請求頭帶上 Authorization: Bearer <token>。（手動放在請求頭不受 CORS 限制，不怕 CSRF）

這樣能夠用於自家登陸，也能夠用於第三方登陸。單點登陸也是 JWT 的經常使用領域。

JWT 也由於信息儲存在客戶端形成沒法讓本身失效的問題，這算是 JWT 的一個缺點。

HTTP authentication

HTTP authentication 是一種標準化的校驗方式，不會使用 cookie 和 session 相關技術。請求頭帶有 Authorization: Basic <credentials> 格式的受權字段。

其中 credentials 就是 Base64 編碼的用戶名 + : + 密碼（或 token），之後看到 Basic authentication，意識到就是每次請求都帶上用戶名密碼就行了。

Basic authentication 大概比較適合 serverless，畢竟他沒有運行着的內存，沒法記錄 session，直接每次都帶上驗證就完事了。

OAuth 2.0

OAuth 2.0（RFC 6749）也是用 token 受權的一種協議，它的特色是你能夠在有限範圍內使用別家接口，也能夠藉此使用別家的登陸系統登陸自家應用，也就是第三方應用登陸。（注意啦注意啦，OAuth 2.0 受權流程說不定面試會考哦！）

既然是第三方登陸，那除了應用自己，一定存在第三方登陸服務器。在 OAuth 2.0 中涉及三個角色：用戶、應用提供方、登陸平臺，相互調用關係以下：

+--------+                               +---------------+
     |        |--(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 ---|               |
     +--------+                               +---------------+

不少大公司都提供 OAuth 2.0 第三方登陸，這裏就拿小聾哥的微信舉例吧——

準備

通常來講，應用提供方須要先在登陸平臺申請好 AppID 和 AppSecret。（微信使用這個名稱，其餘平臺也差很少，一個 ID 和一個 Secret）

獲取 code

什麼是受權臨時票據（code）？ 答：第三方經過 code 進行獲取 access_token 的時候須要用到，code 的超時時間爲 10 分鐘，一個 code 只能成功換取一次 access_token 即失效。code 的臨時性和一次保障了微信受權登陸的安全性。第三方可經過使用 https 和 state 參數，進一步增強自身受權登陸的安全性。

在這一步中，用戶先在登陸平臺進行身份校驗。

https://open.weixin.qq.com/connect/qrconnect?
appid=APPID&
redirect_uri=REDIRECT_URI&
response_type=code&
scope=SCOPE&
state=STATE
#wechat_redirect
參數 是否必須 說明
appid 是 應用惟一標識
redirect_uri 是 請使用 urlEncode 對連接進行處理
response_type 是 填 code
scope 是 應用受權做用域，擁有多個做用域用逗號（,）分隔，網頁應用目前僅填寫 snsapi_login
state 否 用於保持請求和回調的狀態，受權請求後原樣帶回給第三方。該參數可用於防止 csrf 攻擊（跨站請求僞造攻擊）

注意一下 scope 是 OAuth2.0 權限控制的特色，定義了這個 code 換取的 token 能夠用於什麼接口。

正確配置參數後，打開這個頁面看到的是受權頁面，在用戶受權成功後，登陸平臺會帶着 code 跳轉到應用提供方指定的 redirect_uri：

redirect_uri?code=CODE&state=STATE

受權失敗時，跳轉到

redirect_uri?state=STATE

也就是失敗時沒 code。

獲取 token

在跳轉到重定向 URI 以後，應用提供方的後臺須要使用微信給你的code獲取 token，同時，你也能夠用傳回來的 state 進行來源校驗。

要獲取 token，傳入正確參數訪問這個接口：

https://api.weixin.qq.com/sns/oauth2/access_token?
appid=APPID&
secret=SECRET&
code=CODE&
grant_type=authorization_code
參數 是否必須 說明
appid 是 應用惟一標識，在微信開放平臺提交應用審覈經過後得到
secret 是 應用密鑰 AppSecret，在微信開放平臺提交應用審覈經過後得到
code 是 填寫第一步獲取的 code 參數
grant_type 是 填 authorization_code，是其中一種受權模式，微信如今只支持這一種

正確的返回：

{
  "access_token": "ACCESS_TOKEN",
  "expires_in": 7200,
  "refresh_token": "REFRESH_TOKEN",
  "openid": "OPENID",
  "scope": "SCOPE",
  "unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"
}

獲得 token 以後你就能夠根據以前申請 code 填寫的 scope 調用接口了。

使用 token 調用微信接口

受權做用域（scope） 接口 接口說明
snsapi_base /sns/oauth2/access_token 經過 code 換取 access_token、refresh_token 和已受權 scope
snsapi_base /sns/oauth2/refresh_token 刷新或續期 access_token 使用
snsapi_base /sns/auth 檢查 access_token 有效性
snsapi_userinfo /sns/userinfo 獲取用戶我的信息

例如獲取我的信息就是 GET https://api.weixin.qq.com/sns...

注意啦，在微信 OAuth 2.0，access_token 使用 query 傳輸，而不是上面提到的 Authorization。

使用 Authorization 的例子，如 GitHub 的受權，前面的步驟基本一致，在獲取 token 後，這樣請求接口：

curl -H "Authorization: token OAUTH-TOKEN" https://api.github.com

說回微信的 userinfo 接口，返回的數據格式以下：

{
  "openid": "OPENID",
  "nickname": "NICKNAME",
  "sex": 1,
  "province":"PROVINCE",
  "city":"CITY",
  "country":"COUNTRY",
  "headimgurl":"https://thirdwx.qlogo.cn/mmopen/g3MonUZtNHkdmzicIlibx6iaFqAc56vxLSUfpb6n5WKSYVY0ChQKkiaJSgQ1dZuTOgvLLrhJbERQQ4eMsv84eavHiaiceqxibJxCfHe/46",
  "privilege":[ "PRIVILEGE1" "PRIVILEGE2" ],
  "unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"
}

後續使用

在使用 token 獲取用戶我的信息後，你能夠接着用 userinfo 接口返回的 openid，結合 session 技術實如今本身服務器登陸。

// 登陸
req.session.id = openid
if (req.session.id) {
  //   已登陸
} else {
  //   未登陸
}
// 退出
req.session.id = null
// 清除 session

總結一下 OAuth2.0 的流程和重點：

  • 爲你的應用申請 ID 和 Secret
  • 準備好重定向接口
  • 正確傳參獲取 code <- 重要
  • code 傳入你的重定向接口
  • 在重定向接口中使用 code 獲取 token <- 重要
  • 傳入 token 使用微信接口

OAuth2.0 着重於第三方登陸和權限限制。並且 OAuth2.0 不止微信使用的這一種受權方式，其餘方式能夠看阮老師的OAuth 2.0 的四種方式。

其餘方法

JWT 和 OAuth2.0 都是成體系的鑑權方法，不表明登陸系統就必定要這麼複雜。

簡單登陸系統其實就以上面兩種 session 儲存方式爲基礎就能作到。

  1. 使用服務器儲存 session 爲基礎，能夠用相似 req.session.isLogin = true 的方法標誌該 session 的狀態爲已登陸。
  2. 使用客戶端儲存 session 爲基礎，設置 session 的過時日期和登陸人就基本能用了。
{
  "exp": 1614088104313,
  "usr": "admin"
}

（就是和 JWT 原理基本同樣，不過沒有一套體系）

  1. 甚至你可使用上面的知識本身寫一個 express 的登陸系統：
  • 初始化一個 store，內存、redis、數據庫均可以
  • 在用戶身份驗證成功後，隨機生成一串哈希碼做爲 token
  • 用 set-cookie 寫到客戶端
  • 再在服務器寫入登陸狀態，之內存爲例就是在 store 中添加哈希碼做爲屬性
  • 下次請求帶着 cookie 的話檢查 cookie 帶來的 token 是否已經寫入 store 中便可
let store = {}

// 登陸成功後
store[HASH] = true
cookie.set('token', HASH)

// 須要鑑權的請求鍾
const hash = cookie.get('token')
if (store[hash]) {
  // 已登陸
} else {
  // 未登陸
}

// 退出
const hash = cookie.get('token')
delete store[hash]

總結

如下列出本文重點：

  • cookie 是儲存 session/session id/token 的容器
  • cookie 設置通常經過 set-cookie 請求頭設置
  • session 信息能夠存放在瀏覽器，也能夠存放在服務器
  • session 存放在服務器時，以 session id 爲鑰匙獲取信息
  • token/session/session id 三者的界限是模糊的
  • 通常新技術使用 token，傳統技術使用 session id
  • cookie/token/session/session id 都是用於鑑權的實用技術
  • JWT 是瀏覽器儲存 session 的一種
  • JWT 經常使用於單點登陸（SSO）
  • OAuth2.0 的 token 不是由應用端頒發，存在另外的受權服務器
  • OAuth2.0 經常使用於第三方應用登陸

參考

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程