Cookie/Session/Token的區(qū)別有哪些

本篇內(nèi)容主要講解“Cookie/Session/Token的區(qū)別有哪些”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“Cookie/Session/Token的區(qū)別有哪些”吧!

10年積累的成都網(wǎng)站制作、做網(wǎng)站、外貿(mào)營(yíng)銷網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有清澗免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

Cookie

眾所周知，http 是無(wú)狀態(tài)協(xié)議，瀏覽器和服務(wù)器不可能憑協(xié)議的實(shí)現(xiàn)辨別請(qǐng)求的上下文。

于是 cookie 登場(chǎng)，既然協(xié)議本身不能分辨鏈接，那就在請(qǐng)求頭部手動(dòng)帶著上下文信息吧。

舉個(gè)例子，以前去旅游的時(shí)候，到了景區(qū)可能會(huì)需要存放行李，被大包小包壓著，旅游也不開心啦。在存放行李后，服務(wù)員會(huì)給你一個(gè)牌子，上面寫著你的行李放在哪個(gè)格子，離開時(shí)，你就能憑這個(gè)牌子和上面的數(shù)字成功取回行李。

cookie 做的正是這么一件事，旅客就像客戶端，寄存處就像服務(wù)器，憑著寫著數(shù)字的牌子，寄存處（服務(wù)器）就能分辨出不同旅客（客戶端）。

你會(huì)不會(huì)想到，如果牌子被偷了怎么辦，cookie 也會(huì)被偷嗎？確實(shí)會(huì)，這就是一個(gè)很常被提到的網(wǎng)絡(luò)安全問(wèn)題——CSRF?？梢栽谶@篇文章了解關(guān)于 CSRF 的成因和應(yīng)對(duì)方法。

cookie 誕生初似乎是用于電商存放用戶購(gòu)物車一類的數(shù)據(jù)，但現(xiàn)在前端擁有兩個(gè) storage（local、session），兩種數(shù)據(jù)庫(kù)（websql、IndexedDB），根本不愁信息存放問(wèn)題，所以現(xiàn)在基本上 100% 都是在連接上證明客戶端的身份。例如登錄之后，服務(wù)器給你一個(gè)標(biāo)志，就存在 cookie 里，之后再連接時(shí)，都會(huì)自動(dòng)帶上 cookie，服務(wù)器便分清誰(shuí)是誰(shuí)。另外，cookie 還可以用于跟蹤一個(gè)用戶，這就產(chǎn)生了隱私問(wèn)題，于是也就有了“禁用 cookie”這個(gè)選項(xiàng)（然而現(xiàn)在這個(gè)時(shí)代禁用 cookie 是挺麻煩的事情）。

設(shè)置方式

現(xiàn)實(shí)世界的例子明白了，在計(jì)算機(jī)中怎么才能設(shè)置 cookie 呢？一般來(lái)說(shuō)，安全起見(jiàn)，cookie 都是依靠 set-cookie 頭設(shè)置，且不允許 JavaScript 設(shè)置。

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 對(duì)，內(nèi)容隨你定，另外還有 HttpOnly、SameSite 等配置，一條 Set-Cookie 只配置一項(xiàng) cookie。

Cookie/Session/Token的區(qū)別有哪些

  •  Expires 設(shè)置 cookie 的過(guò)期時(shí)間（時(shí)間戳），這個(gè)時(shí)間是客戶端時(shí)間。

  •  Max-Age 設(shè)置 cookie 的保留時(shí)長(zhǎng)（秒數(shù)），同時(shí)存在 Expires 和 Max-Age 的話，Max-Age 優(yōu)先

  •  Domain 設(shè)置生效的域名，默認(rèn)就是當(dāng)前域名，不包含子域名

  •  Path 設(shè)置生效路徑，/ 全匹配

  •  Secure 設(shè)置 cookie 只在 https 下發(fā)送，防止中間人攻擊

  •  HttpOnly 設(shè)置禁止 JavaScript 訪問(wèn) cookie，防止XSS

  •  SameSite 設(shè)置跨域時(shí)不攜帶 cookie，防止CSRF

Secure 和 HttpOnly 是強(qiáng)烈建議開啟的。SameSite 選項(xiàng)需要根據(jù)實(shí)際情況討論，因?yàn)?SameSite 可能會(huì)導(dǎo)致即使你用 CORS 解決了跨越問(wèn)題，依然會(huì)因?yàn)檎?qǐng)求沒(méi)自帶 cookie 引起一系列問(wèn)題，一開始還以為是 axios 配置問(wèn)題，繞了一大圈，然而根本沒(méi)關(guān)系。

其實(shí)因?yàn)?Chrome 在某一次更新后把沒(méi)設(shè)置 SameSite 默認(rèn)為 Lax，你不在服務(wù)器手動(dòng)把 SameSite 設(shè)置為 None 就不會(huì)自動(dòng)帶 cookie 了。

發(fā)送方式

參考 MDN，cookie 的發(fā)送格式如下（其中 PHPSESSID 相關(guān)內(nèi)容下面會(huì)提到）：

Cookie: <cookie-list>  Cookie: name=value  Cookie: name=value; name2=value2; name3=value3  Cookie: PHPSESSID=298zf09hf012fh3; csrftoken=u32t4o3tb3gg43; _gat=1

在發(fā)送 cookie 時(shí)，并不會(huì)傳上面提到的配置到服務(wù)器，因?yàn)榉?wù)器在設(shè)置后就不需要關(guān)心這些信息了，只要現(xiàn)代瀏覽器運(yùn)作正常，收到的 cookie 就是沒(méi)問(wèn)題的。

Session

從 cookie 說(shuō)到 session，是因?yàn)?session 才是真正的“信息”，如上面提到的，cookie 是容器，里面裝著 PHPSESSID=298zf09hf012fh3;，這就是一個(gè) session ID。

不知道 session 和 session id 會(huì)不會(huì)讓你看得有點(diǎn)頭暈？

當(dāng)初 session 的存在就是要為客戶端和服務(wù)器連接提供的信息，所以我將 session 理解為信息，而 session id 是獲取信息的鑰匙，通常是一串唯一的哈希碼。

接下來(lái)分析兩個(gè) node.js express 的中間件，理解兩種 session 的實(shí)現(xiàn)方式。

session 信息可以儲(chǔ)存在客戶端，如 cookie-session，也可以儲(chǔ)存在服務(wù)器，如 express-session。使用 session ID 就是把 session 放在服務(wù)器里，用 cookie 里的 id 尋找服務(wù)器的信息。

客戶端儲(chǔ)存

對(duì)于 cookie-session 庫(kù)，比較容易理解，其實(shí)就是把所有信息加密后塞到 cookie 里。其中涉及到 cookies 庫(kù)。在設(shè)置 session 時(shí)其實(shí)就是調(diào)用 cookies.set，把信息寫到 set-cookie 里，再返回瀏覽器。換言之，取值和賦值的本質(zhì)都是操作 cookie。

瀏覽器在接收到 set-cookie 頭后，會(huì)把信息寫到 cookie 里。在下次發(fā)送請(qǐng)求時(shí)，信息又通過(guò) cookie 原樣帶回來(lái)，所以服務(wù)器什么東西都不用存，只負(fù)責(zé)獲取和處理 cookie 里的信息，這種實(shí)現(xiàn)方法不需要 session ID。

這是一段使用 cookie-session 中間件為請(qǐng)求添加 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)

在通過(guò) app.use(cookieSession()) 使用中間件之前，請(qǐng)求是不會(huì)設(shè)置 cookie 的，添加后再訪問(wèn)（并且在設(shè)置 req.session 后，若不添加 session 信息就沒(méi)必要寫、也沒(méi)內(nèi)容寫到 cookie 里），就能看到服務(wù)器響應(yīng)頭部新增了下面兩行，分別寫入 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 標(biāo)簽看到 cookie 成功寫入。session 的值 eyJ0ZXN0IjoiaGV5In0= 通過(guò) base64 解碼（不了解 base64 的話可以看這里）即可得到 {"test":"hey"}，這就是所謂的“將 session 信息放到客戶端”，因?yàn)?base64 編碼并不是加密，這就跟明文傳輸沒(méi)啥區(qū)別，所以請(qǐng)不要在客戶端 session 里放用戶密碼之類的機(jī)密信息。

即使現(xiàn)代瀏覽器和服務(wù)器做了一些約定，例如使用 https、跨域限制、還有上面提到 cookie 的 httponly 和 sameSite 配置等，保障了 cookie 安全。但是想想，傳輸安全保障了，如果有人偷看你電腦里的 cookie，密碼又恰好存在 cookie，那就能無(wú)聲無(wú)息地偷走密碼。相反的，只放其他信息或是僅僅證明“已登錄”標(biāo)志的話，只要退出一次，這個(gè) cookie 就失效了，算是降低了潛在危險(xiǎn)。

說(shuō)回第二個(gè)值 session.sig，它是一個(gè) 27 字節(jié)的 SHA1 簽名，用以校驗(yàn) session 是否被篡改，是 cookie 安全的又一層保障。

服務(wù)器儲(chǔ)存

既然要儲(chǔ)存在服務(wù)器，那么 express-session 就需要一個(gè)容器 store，它可以是內(nèi)存、redis、MongoDB 等等等等，內(nèi)存應(yīng)該是最快的，但是重啟程序就沒(méi)了，redis 可以作為備選，用數(shù)據(jù)庫(kù)存 session 的場(chǎng)景感覺(jué)不多。

express-session 的源碼沒(méi) cookie-session 那么簡(jiǎn)明易懂，里面有一個(gè)有點(diǎn)繞的問(wèn)題，req.session 到底是怎么插入的？

不關(guān)注實(shí)現(xiàn)可以跳過(guò)這段，有興趣的話可以跟著思路看看 express-session 的源碼。

我們可以從 .session = 這個(gè)關(guān)鍵詞開始找，找到：

  •  store.generate 否決這個(gè)，容易看出這個(gè)是初始化使用的

  •  Store.prototype.createSession 這個(gè)是根據(jù) req 和 sess 參數(shù)在 req 中設(shè)置 session 屬性，沒(méi)錯(cuò)，就是你了

于是全局搜索 createSession，鎖定 index 里的 inflate （就是填充的意思）函數(shù)。

最后尋找 inflate 的調(diào)用點(diǎn)，是使用 sessionID 為參數(shù)的 store.get 的回調(diào)函數(shù)，一切說(shuō)得通啦&mdash;&mdash;

在監(jiān)測(cè)到客戶端送來(lái)的 cookie 之后，可以從 cookie 獲取 sessionID，再使用 id 在 store 中獲取 session 信息，掛到 req.session，經(jīng)過(guò)這個(gè)中間件，你就能順利地使用 req 中的 session。

那賦值怎么辦呢？這就和上面儲(chǔ)存在客戶端不同了，上面要修改客戶端 cookie 信息，但是對(duì)于儲(chǔ)存在服務(wù)器的情況，你修改了 session 那就是“實(shí)實(shí)在在地修改”了嘛，不用其他花里胡哨的方法，內(nèi)存中的信息就是修改了，下次獲取內(nèi)存里的對(duì)應(yīng)信息也是修改后的信息。（僅限于內(nèi)存的實(shí)現(xiàn)方式，使用數(shù)據(jù)庫(kù)時(shí)仍需要額外的寫入）

在請(qǐng)求沒(méi)有 session id 的情況下，通過(guò) store.generate 創(chuàng)建新的 session，在你寫 session 的時(shí)候，cookie 可以不改變，只要根據(jù)原來(lái)的 cookie 訪問(wèn)內(nèi)存里的 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)

兩種儲(chǔ)存方式的對(duì)比

首先還是計(jì)算機(jī)世界最重要的哲學(xué)問(wèn)題：時(shí)間和空間的抉擇。

儲(chǔ)存在客戶端的情況，解放了服務(wù)器存放 session 的內(nèi)存，但是每次都帶上一堆 base64 處理的 session 信息，如果量大的話傳輸就會(huì)很緩慢。

儲(chǔ)存在服務(wù)器相反，用服務(wù)器的內(nèi)存拯救了帶寬。

另外，在退出登錄的實(shí)現(xiàn)和結(jié)果，也是有區(qū)別的。

儲(chǔ)存在服務(wù)器的情況就很簡(jiǎn)單，如果 req.session.isLogin = true 是登錄，那么 req.session.isLogin = false 就是退出。

但是狀態(tài)存放在客戶端要做到真正的“即時(shí)退出登錄”就很困難了。你可以在 session 信息里加上過(guò)期日期，也可以直接依靠 cookie 的過(guò)期日期，過(guò)期之后，就當(dāng)是退出了。

但是如果你不想等到 session 過(guò)期，現(xiàn)在就想退出登錄！怎么辦？認(rèn)真想想你會(huì)發(fā)現(xiàn)，僅僅依靠客戶端儲(chǔ)存的 session 信息真的沒(méi)有辦法做到。

即使你通過(guò) req.session = null 刪掉客戶端 cookie，那也只是刪掉了，但是如果有人曾經(jīng)把 cookie 復(fù)制出來(lái)了，那他手上的 cookie 直到 session 信息里的過(guò)期時(shí)間前，都是有效的。

說(shuō)“即時(shí)退出登錄”有點(diǎn)標(biāo)題黨的意味，其實(shí)我想表達(dá)的是，你沒(méi)辦法立即廢除一個(gè) session，這可能會(huì)造成一些隱患。

Token

session 說(shuō)完了，那么出現(xiàn)頻率超高的關(guān)鍵字 token 又是什么？

不妨谷歌搜一下 token 這個(gè)詞，可以看到冒出來(lái)幾個(gè)（年紀(jì)大的人）比較熟悉的圖片：密碼器。過(guò)去網(wǎng)上銀行不是只要短信認(rèn)證就能轉(zhuǎn)賬，還要經(jīng)過(guò)一個(gè)密碼器，上面顯示著一個(gè)變動(dòng)的密碼，在轉(zhuǎn)賬時(shí)你需要輸入密碼器中的代碼才能轉(zhuǎn)賬，這就是 token 現(xiàn)實(shí)世界中的例子。憑借一串碼或是一個(gè)數(shù)字證明自己身份，這事情不就和上面提到的行李問(wèn)題還是一樣的嗎&hellip;&hellip;

其實(shí)本質(zhì)上 token 的功能就是和 session id 一模一樣。你把 session id 說(shuō)成 session token 也沒(méi)什么問(wèn)題（Wikipedia 里就寫了這個(gè)別名）。

其中的區(qū)別在于，session id 一般存在 cookie 里，自動(dòng)帶上；token 一般是要你主動(dòng)放在請(qǐng)求中，例如設(shè)置請(qǐng)求頭的 Authorization 為 bearer:<access_token>。

然而上面說(shuō)的都是一般情況，根本沒(méi)有明確規(guī)定！

劇透一下，下面要講的 JWT（JSON Web Token）！他是一個(gè) token！但是里面放著 session 信息！放在客戶端，并且可以隨你選擇放在 cookie 或是手動(dòng)添加在 Authorization！但是他就叫 token！

個(gè)人覺(jué)得你不能通過(guò)存放的位置判斷是 token 或是 session id，也不能通過(guò)內(nèi)容判斷是 token 或是 session 信息，session、session id 以及 token 都是很意識(shí)流的東西，只要你明白他是什么、怎么用就好了，怎么稱呼不太重要。

另外在搜索資料時(shí)也看到有些文章說(shuō) session 和 token 的區(qū)別就是新舊技術(shù)的區(qū)別，好像有點(diǎn)道理。

在 session 的 Wikipedia 頁(yè)面上 HTTP session token 這一欄，舉例都是 JSESSIONID (JSP)、PHPSESSID (PHP)、CGISESSID (CGI)、ASPSESSIONID (ASP) 等比較傳統(tǒng)的技術(shù)，就像 SESSIONID 是他們的代名詞一般；而在研究現(xiàn)在各種平臺(tái)的 API 接口和 OAuth3.0 登錄時(shí)，都是使用 access token 這樣的字眼，這個(gè)區(qū)別著實(shí)有點(diǎn)意思。

理解 session 和 token 的聯(lián)系之后，可以在哪里能看到“活的” token 呢？

打開 GitHub 進(jìn)入設(shè)置，找到 Settings / Developer settings，可以看到 Personal access tokens 選項(xiàng)，生成新的 token 后，你就可以帶著它通過(guò) GitHub API，證明“你就是你”。

在 OAuth 系統(tǒng)中也使用了 Access token 這個(gè)關(guān)鍵詞，寫過(guò)微信登錄的朋友應(yīng)該都能感受到 token 是個(gè)什么啦。

Token 在權(quán)限證明上真的很重要，不可泄漏，誰(shuí)拿到 token，誰(shuí)就是“主人”。所以要做一個(gè) Token 系統(tǒng)，刷新或刪除 Token 是必須要的，這樣在盡快彌補(bǔ) token 泄漏的問(wèn)題。

在理解了三個(gè)關(guān)鍵字和兩種儲(chǔ)存方式之后，下面我們正式開始說(shuō)“用戶登錄”相關(guān)的知識(shí)和兩種登錄規(guī)范&mdash;&mdash;JWT 和 OAuth3.0。

接著你可能會(huì)頻繁見(jiàn)到 Authentication 和 Authorization 這兩個(gè)單詞，它們都是 Auth 開頭，但可不是一個(gè)意思，簡(jiǎn)單來(lái)說(shuō)前者是驗(yàn)證，后者是授權(quán)。在編寫登錄系統(tǒng)時(shí)，要先驗(yàn)證用戶身份，設(shè)置登錄狀態(tài)，給用戶發(fā)送 token 就是授權(quán)。

JWT

全稱 JSON Web Token（RFC 7519），是的，JWT 就是一個(gè) token。為了方便理解，提前告訴大家，JWT 用的是上面客戶端儲(chǔ)存的方式，所以這部分可能會(huì)經(jīng)常用到上面提到的名稱。

結(jié)構(gòu)

雖說(shuō) JWT 就是客戶端儲(chǔ)存 session 信息的一種，但是 JWT 有著自己的結(jié)構(gòu)：Header.Payload.Signature（分為三個(gè)部分，用 . 隔開）

Header

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

typ 說(shuō)明 token 類型是 JWT，alg 代表簽名算法，HMAC、SHA256、RSA 等。然后將其 base64 編碼。

Payload

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

Payload 是放置 session 信息的位置，最后也要將這些信息進(jìn)行 base64 編碼，結(jié)果就和上面客戶端儲(chǔ)存的 session 信息差不多。

不過(guò) JWT 有一些約定好的屬性，被稱為 Registered claims，包括：

  •  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)

Signature

最后一部分是簽名，和上面提到的 session.sig 一樣是用于防止篡改，不過(guò) JWT 把簽名和內(nèi)容組合到一起罷了。

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

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

使用 Header 里 alg 的算法和自己設(shè)定的密鑰 secret 編碼 base64UrlEncode(header) + "." + base64UrlEncode(payload)

最后將三部分通過(guò) . 組合在一起，你可以通過(guò) jwt.io Debugger 形象地看到 JWT 的組成原理：

Cookie/Session/Token的區(qū)別有哪些

如何使用

在驗(yàn)證用戶，順利登錄后，會(huì)給用戶返回 JWT。因?yàn)?JWT 的信息沒(méi)有加密，所以別往里面放密碼，詳細(xì)原因在客戶端儲(chǔ)存的 cookie 中提到。

用戶訪問(wèn)需要授權(quán)的連接時(shí)，可以把 token 放在 cookie，也可以在請(qǐng)求頭帶上 Authorization: Bearer <token>。（手動(dòng)放在請(qǐng)求頭不受 CORS 限制，不怕 CSRF）

這樣可以用于自家登錄，也可以用于第三方登錄。單點(diǎn)登錄也是 JWT 的常用領(lǐng)域。

JWT 也因?yàn)樾畔?chǔ)存在客戶端造成無(wú)法讓自己失效的問(wèn)題，這算是 JWT 的一個(gè)缺點(diǎn)。

HTTP authentication

HTTP authentication 是一種標(biāo)準(zhǔn)化的校驗(yàn)方式，不會(huì)使用 cookie 和 session 相關(guān)技術(shù)。請(qǐng)求頭帶有 Authorization: Basic <credentials> 格式的授權(quán)字段。

其中 credentials 就是 Base64 編碼的用戶名 + : + 密碼（或 token），以后看到 Basic authentication，意識(shí)到就是每次請(qǐng)求都帶上用戶名密碼就好了。

Basic authentication 大概比較適合 serverless，畢竟他沒(méi)有運(yùn)行著的內(nèi)存，無(wú)法記錄 session，直接每次都帶上驗(yàn)證就完事了。

OAuth 2.0

OAuth 2.0（RFC 6749）也是用 token 授權(quán)的一種協(xié)議，它的特點(diǎn)是你可以在有限范圍內(nèi)使用別家接口，也可以借此使用別家的登錄系統(tǒng)登錄自家應(yīng)用，也就是第三方應(yīng)用登錄。（注意啦注意啦，OAuth 2.0 授權(quán)流程說(shuō)不定面試會(huì)考哦?。?/p>

既然是第三方登錄，那除了應(yīng)用本身，必定存在第三方登錄服務(wù)器。在 OAuth 2.0 中涉及三個(gè)角色：用戶、應(yīng)用提供方、登錄平臺(tái)，相互調(diào)用關(guān)系如下：

+--------+                               +---------------+  |        |--(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 第三方登錄，這里就拿小聾哥的微信舉例吧&mdash;&mdash;

準(zhǔn)備

一般來(lái)說(shuō)，應(yīng)用提供方需要先在登錄平臺(tái)申請(qǐng)好 AppID 和 AppSecret。（微信使用這個(gè)名稱，其他平臺(tái)也差不多，一個(gè) ID 和一個(gè) Secret）

獲取 code

什么是授權(quán)臨時(shí)票據(jù)（code）？ 答：第三方通過(guò) code 進(jìn)行獲取 access_token 的時(shí)候需要用到，code 的超時(shí)時(shí)間為 10 分鐘，一個(gè) code 只能成功換取一次 access_token 即失效。code 的臨時(shí)性和一次保障了微信授權(quán)登錄的安全性。第三方可通過(guò)使用 https 和 state 參數(shù)，進(jìn)一步加強(qiáng)自身授權(quán)登錄的安全性。

在這一步中，用戶先在登錄平臺(tái)進(jìn)行身份校驗(yàn)。

https://open.weixin.qq.com/connect/qrconnect?  appid=APPID&  redirect_uri=REDIRECT_URI&  response_type=code&  scope=SCOPE&  state=STATE  #wechat_redirect
參數(shù)是否必須說(shuō)明
appid是應(yīng)用唯一標(biāo)識(shí)
redirect_uri是請(qǐng)使用 urlEncode 對(duì)鏈接進(jìn)行處理
response_type是填 code
scope是應(yīng)用授權(quán)作用域，擁有多個(gè)作用域用逗號(hào)（,）分隔，網(wǎng)頁(yè)應(yīng)用目前僅填寫 snsapi_login
state否用于保持請(qǐng)求和回調(diào)的狀態(tài)，授權(quán)請(qǐng)求后原樣帶回給第三方。該參數(shù)可用于防止 csrf 攻擊（跨站請(qǐng)求偽造攻擊）

注意一下 scope 是 OAuth3.0 權(quán)限控制的特點(diǎn)，定義了這個(gè) code 換取的 token 可以用于什么接口。

正確配置參數(shù)后，打開這個(gè)頁(yè)面看到的是授權(quán)頁(yè)面，在用戶授權(quán)成功后，登錄平臺(tái)會(huì)帶著 code 跳轉(zhuǎn)到應(yīng)用提供方指定的 redirect_uri：

redirect_uri?code=CODE&state=STATE

授權(quán)失敗時(shí)，跳轉(zhuǎn)到

redirect_uri?state=STATE

也就是失敗時(shí)沒(méi) code。

獲取 token

在跳轉(zhuǎn)到重定向 URI 之后，應(yīng)用提供方的后臺(tái)需要使用微信給你的code獲取 token，同時(shí)，你也可以用傳回來(lái)的 state 進(jìn)行來(lái)源校驗(yàn)。

要獲取 token，傳入正確參數(shù)訪問(wèn)這個(gè)接口：

https://api.weixin.qq.com/sns/oauth3/access_token?  appid=APPID& secret=SECRET&  code=CODE&  grant_type=authorization_code
參數(shù)是否必須說(shuō)明
appid是應(yīng)用唯一標(biāo)識(shí)，在微信開放平臺(tái)提交應(yīng)用審核通過(guò)后獲得
secret是應(yīng)用密鑰 AppSecret，在微信開放平臺(tái)提交應(yīng)用審核通過(guò)后獲得
code是填寫第一步獲取的 code 參數(shù)
grant_type是填 authorization_code，是其中一種授權(quán)模式，微信現(xiàn)在只支持這一種

正確的返回：

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

得到 token 之后你就可以根據(jù)之前申請(qǐng) code 填寫的 scope 調(diào)用接口了。

使用 token 調(diào)用微信接口

授權(quán)作用域（scope）接口接口說(shuō)明
snsapi_base/sns/oauth3/access_token通過(guò) code 換取 access_token、refresh_token 和已授權(quán) scope
snsapi_base/sns/oauth3/refresh_token刷新或續(xù)期 access_token 使用
snsapi_base/sns/auth檢查 access_token 有效性
snsapi_userinfo/sns/userinfo獲取用戶個(gè)人信息

例如獲取個(gè)人信息就是 GET https://api.weixin.qq.com/sns...

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

使用 Authorization 的例子，如 GitHub 的授權(quán)，前面的步驟基本一致，在獲取 token 后，這樣請(qǐng)求接口：

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

說(shuō)回微信的 userinfo 接口，返回的數(shù)據(jù)格式如下：

{    "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"  }

后續(xù)使用

在使用 token 獲取用戶個(gè)人信息后，你可以接著用 userinfo 接口返回的 openid，結(jié)合 session 技術(shù)實(shí)現(xiàn)在自己服務(wù)器登錄。

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

總結(jié)一下 OAuth3.0 的流程和重點(diǎn)：

  •  為你的應(yīng)用申請(qǐng) ID 和 Secret

  •  準(zhǔn)備好重定向接口

  •  正確傳參獲取 code <- 重要

  •  code 傳入你的重定向接口

  •  在重定向接口中使用 code 獲取 token <- 重要

  •  傳入 token 使用微信接口

OAuth3.0 著重于第三方登錄和權(quán)限限制。而且 OAuth3.0 不止微信使用的這一種授權(quán)方式，其他方式可以看阮老師的OAuth 2.0 的四種方式。

其他方法

JWT 和 OAuth3.0 都是成體系的鑒權(quán)方法，不代表登錄系統(tǒng)就一定要這么復(fù)雜。

簡(jiǎn)單登錄系統(tǒng)其實(shí)就以上面兩種 session 儲(chǔ)存方式為基礎(chǔ)就能做到。

  1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

  2.  使用服務(wù)器儲(chǔ)存 session 為基礎(chǔ)，可以用類似 req.session.isLogin = true 的方法標(biāo)志該 session 的狀態(tài)為已登錄。

  3.  使用客戶端儲(chǔ)存 session 為基礎(chǔ)，設(shè)置 session 的過(guò)期日期和登錄人就基本能用了。 

{    "exp": 1614088104313,    "usr": "admin"  }

（就是和 JWT 原理基本一樣，不過(guò)沒(méi)有一套體系）

  1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

  2.  甚至你可以使用上面的知識(shí)自己寫一個(gè) express 的登錄系統(tǒng)：

  •  初始化一個(gè) store，內(nèi)存、redis、數(shù)據(jù)庫(kù)都可以

  •  在用戶身份驗(yàn)證成功后，隨機(jī)生成一串哈希碼作為 token

  •  用 set-cookie 寫到客戶端

  •  再在服務(wù)器寫入登錄狀態(tài)，以內(nèi)存為例就是在 store 中添加哈希碼作為屬性

  •  下次請(qǐng)求帶著 cookie 的話檢查 cookie 帶來(lái)的 token 是否已經(jīng)寫入 store 中即可 

let store = {}  // 登錄成功后  store[HASH] = true  cookie.set('token', HASH)  // 需要鑒權(quán)的請(qǐng)求鐘  const hash = cookie.get('token')  if (store[hash]) {    // 已登錄  } else {    // 未登錄  }   // 退出  const hash = cookie.get('token')  delete store[hash]

總結(jié)

以下列出本文重點(diǎn)：

  •  cookie 是儲(chǔ)存 session/session id/token 的容器

  •  cookie 設(shè)置一般通過(guò) set-cookie 請(qǐng)求頭設(shè)置

  •  session 信息可以存放在瀏覽器，也可以存放在服務(wù)器

  •  session 存放在服務(wù)器時(shí)，以 session id 為鑰匙獲取信息

  •  token/session/session id 三者的界限是模糊的

  •  一般新技術(shù)使用 token，傳統(tǒng)技術(shù)使用 session id

  •  cookie/token/session/session id 都是用于鑒權(quán)的實(shí)用技術(shù)  JWT 是瀏覽器儲(chǔ)存 session 的一種

  •  JWT 常用于單點(diǎn)登錄（SSO）

  •  OAuth3.0 的 token 不是由應(yīng)用端頒發(fā)，存在另外的授權(quán)服務(wù)器

  •  OAuth3.0 常用于第三方應(yīng)用登錄 

到此，相信大家對(duì)“Cookie/Session/Token的區(qū)別有哪些”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

分享名稱：Cookie/Session/Token的區(qū)別有哪些
本文地址：http://muchs.cn/article40/pjpoho.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供動(dòng)態(tài)網(wǎng)站、建站公司、網(wǎng)站導(dǎo)航、響應(yīng)式網(wǎng)站、網(wǎng)站收錄、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)

成都app開發(fā)公司