共計(jì) 2216 個(gè)字符，預(yù)計(jì)需要花費(fèi) 6 分鐘才能閱讀完成。

在簡(jiǎn)單理解 cookie/session 機(jī)制這篇文章中，簡(jiǎn)要闡述了 cookie 和 session 的原理。本文將要簡(jiǎn)單闡述另一個(gè)同 cookie/session 同樣重要的技術(shù)術(shù)語(yǔ)：token。

什么是 token

token 的意思是令牌，是服務(wù)端生成的一串字符串，作為客戶端進(jìn)行請(qǐng)求的一個(gè)標(biāo)識(shí)。

當(dāng)用戶第一次登錄后，服務(wù)器生成一個(gè) token 并將此 token 返回給客戶端，以后客戶端只需帶上這個(gè) token 前來(lái)請(qǐng)求數(shù)據(jù)即可，無(wú)需再次帶上用戶名和密碼。

簡(jiǎn)單 token 的組成；uid(用戶唯一的身份標(biāo)識(shí))、time(當(dāng)前時(shí)間的時(shí)間戳)、sign（簽名，token 的前幾位以哈希算法壓縮成的一定長(zhǎng)度的十六進(jìn)制字符串。為防止 token 泄露）。

身份認(rèn)證概述

由于 HTTP 是一種沒(méi)有狀態(tài)的協(xié)議，它并不知道是誰(shuí)訪問(wèn)了我們的應(yīng)用。這里把用戶看成是客戶端，客戶端使用用戶名還有密碼通過(guò)了身份驗(yàn)證，不過(guò)下次這個(gè)客戶端再發(fā)送請(qǐng)求時(shí)候，還得再驗(yàn)證一下。

通用的解決方法就是，當(dāng)用戶請(qǐng)求登錄的時(shí)候，如果沒(méi)有問(wèn)題，在服務(wù)端生成一條記錄，在這個(gè)記錄里可以說(shuō)明登錄的用戶是誰(shuí)，然后把這條記錄的 id 發(fā)送給客戶端，客戶端收到以后把這個(gè) id 存儲(chǔ)在 cookie 里，下次該用戶再次向服務(wù)端發(fā)送請(qǐng)求的時(shí)候，可以帶上這個(gè) cookie，這樣服務(wù)端會(huì)驗(yàn)證一下 cookie 里的信息，看能不能在服務(wù)端這里找到對(duì)應(yīng)的記錄，如果可以，說(shuō)明用戶已經(jīng)通過(guò)了身份驗(yàn)證，就把用戶請(qǐng)求的數(shù)據(jù)返回給客戶端。

以上所描述的過(guò)程就是利用 session，那個(gè) id 值就是 sessionid。我們需要在服務(wù)端存儲(chǔ)為用戶生成的 session，這些 session 會(huì)存儲(chǔ)在內(nèi)存，磁盤，或者數(shù)據(jù)庫(kù)。

基于 token 機(jī)制的身份認(rèn)證

使用 token 機(jī)制的身份驗(yàn)證方法，在服務(wù)器端不需要存儲(chǔ)用戶的登錄記錄。大概的流程：

客戶端使用用戶名和密碼請(qǐng)求登錄。服務(wù)端收到請(qǐng)求，驗(yàn)證用戶名和密碼。驗(yàn)證成功后，服務(wù)端會(huì)生成一個(gè) token，然后把這個(gè) token 發(fā)送給客戶端。客戶端收到 token 后把它存儲(chǔ)起來(lái)，可以放在 cookie 或者 Local Storage（本地存儲(chǔ)）里。客戶端每次向服務(wù)端發(fā)送請(qǐng)求的時(shí)候都需要帶上服務(wù)端發(fā)給的 token。服務(wù)端收到請(qǐng)求，然后去驗(yàn)證客戶端請(qǐng)求里面帶著 token，如果驗(yàn)證成功，就向客戶端返回請(qǐng)求的數(shù)據(jù)。

利用 token 機(jī)制進(jìn)行登錄認(rèn)證，可以有以下方式：

a. 用設(shè)備 mac 地址作為 token

客戶端：客戶端在登錄時(shí)獲取設(shè)備的 mac 地址，將其作為參數(shù)傳遞到服務(wù)端

服務(wù)端：服務(wù)端接收到該參數(shù)后，便用一個(gè)變量來(lái)接收，同時(shí)將其作為 token 保存在數(shù)據(jù)庫(kù)，并將該 token 設(shè)置到 session 中。客戶端每次請(qǐng)求的時(shí)候都要統(tǒng)一攔截，將客戶端傳遞的 token 和服務(wù)器端 session 中的 token 進(jìn)行對(duì)比，相同則登錄成功，不同則拒絕。

此方式客戶端和服務(wù)端統(tǒng)一了唯一的標(biāo)識(shí)，并且保證每一個(gè)設(shè)備擁有唯一的標(biāo)識(shí)。缺點(diǎn)是服務(wù)器端需要保存 mac 地址；優(yōu)點(diǎn)是客戶端無(wú)需重新登錄，只要登錄一次以后一直可以使用，對(duì)于超時(shí)的問(wèn)題由服務(wù)端進(jìn)行處理。

b. 用 sessionid 作為 token

客戶端：客戶端攜帶用戶名和密碼登錄

服務(wù)端：接收到用戶名和密碼后進(jìn)行校驗(yàn)，正確就將本地獲取的 sessionid 作為 token 返回給客戶端，客戶端以后只需帶上請(qǐng)求的數(shù)據(jù)即可。

此方式的優(yōu)點(diǎn)是方便，不用存儲(chǔ)數(shù)據(jù)，缺點(diǎn)就是當(dāng) session 過(guò)期時(shí)，客戶端必須重新登錄才能請(qǐng)求數(shù)據(jù)。

當(dāng)然，對(duì)于一些保密性較高的應(yīng)用，可以采取兩種方式結(jié)合的方式，將設(shè)備 mac 地址與用戶名密碼同時(shí)作為 token 進(jìn)行認(rèn)證。

APP 利用 token 機(jī)制進(jìn)行身份認(rèn)證

用戶在登錄 APP 時(shí)，APP 端會(huì)發(fā)送加密的用戶名和密碼到服務(wù)器，服務(wù)器驗(yàn)證用戶名和密碼，如果驗(yàn)證成功，就會(huì)生成相應(yīng)位數(shù)的字符產(chǎn)作為 token 存儲(chǔ)到服務(wù)器中，并且將該 token 返回給 APP 端。

以后 APP 再次請(qǐng)求時(shí)，凡是需要驗(yàn)證的地方都要帶上該 token，然后服務(wù)器端驗(yàn)證 token，成功返回所需要的結(jié)果，失敗返回錯(cuò)誤信息，讓用戶重新登錄。其中，服務(wù)器上會(huì)給 token 設(shè)置一個(gè)有效期，每次 APP 請(qǐng)求的時(shí)候都驗(yàn)證 token 和有效期。

token 的存儲(chǔ)

token 可以存到數(shù)據(jù)庫(kù)中，但是有可能查詢 token 的時(shí)間會(huì)過(guò)長(zhǎng)導(dǎo)致 token 丟失（其實(shí) token 丟失了再重新認(rèn)證一個(gè)就好，但是別丟太頻繁，別讓用戶沒(méi)事兒就去認(rèn)證）。

為了避免查詢時(shí)間過(guò)長(zhǎng)，可以將 token 放到內(nèi)存中。這樣查詢速度絕對(duì)就不是問(wèn)題了，也不用太擔(dān)心占據(jù)內(nèi)存，就算 token 是一個(gè) 32 位的字符串，應(yīng)用的用戶量在百萬(wàn)級(jí)或者千萬(wàn)級(jí)，也是占不了多少內(nèi)存的。

token 的加密

token 是很容易泄露的，如果不進(jìn)行加密處理，很容易被惡意拷貝并用來(lái)登錄。加密的方式一般有：

在存儲(chǔ)的時(shí)候把 token 進(jìn)行對(duì)稱加密存儲(chǔ)，用到的時(shí)候再解密。文章最開始提到的簽名 sign：將請(qǐng)求 URL、時(shí)間戳、token 三者合并，通過(guò)算法進(jìn)行加密處理。

最好是兩種方式結(jié)合使用。

還有一點(diǎn)，在網(wǎng)絡(luò)層面上 token 使用明文傳輸?shù)脑捠欠浅ＮｋU(xiǎn)的，所以一定要使用 HTTPS 協(xié)議。

總結(jié)

以上就是對(duì)于 token 在用戶身份認(rèn)證過(guò)程中的簡(jiǎn)單總結(jié)。希望沒(méi)有技術(shù)背景的產(chǎn)品經(jīng)理們?cè)诤烷_發(fā)哥哥溝通的時(shí)候不要再被這些技術(shù)術(shù)語(yǔ)問(wèn)住了。

作者：流年，互聯(lián)網(wǎng)產(chǎn)品設(shè)計(jì)師，4 年互聯(lián)網(wǎng)產(chǎn)品設(shè)計(jì)經(jīng)驗(yàn)。

本文由 @流年 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖由作者提供

丸趣 TV 網(wǎng) – 提供最優(yōu)質(zhì)的資源集合！