token、cookie和session的區(qū)別與使用場景？謝謝你的邀請。它是由服務器生成的字符串，用作客戶端請求的令牌。在第一次登錄之后，服務器生成一個令牌并將其返回給客戶端。稍后，客戶端只需要攜帶令

token、cookie和session的區(qū)別與使用場景？

謝謝你的邀請。

它是由服務器生成的字符串，用作客戶端請求的令牌。在第一次登錄之后，服務器生成一個令牌并將其返回給客戶端。稍后，客戶端只需要攜帶令牌來請求數(shù)據(jù)，而不需要再次攜帶用戶名和密碼。

會話表示服務器和瀏覽器之間的會話，它是連續(xù)或間歇的。

cookie中存儲了一個會話ID，請求發(fā)出時將發(fā)送該ID；

由于請求而生成會話（請求對象）；

會話是一個容器，可以在會話期間存儲任何對象；

會話始終在服務器上創(chuàng)建和使用，瀏覽器從不獲取會話對象session是一種HTTP存儲機制，它是為武裝HTTP而設計的一種持久化機制。

，包括cookie技術(shù)。Cookie是存儲在計算機瀏覽器目錄中的文本文件。當瀏覽器運行時，它存儲在RAM（會話cookies）中。一旦用戶退出網(wǎng)站或服務器，cookie就可以存儲在用戶的本地硬盤上。

后端可以讓token直接存到瀏覽器的cookie里嗎？

首先，什么是餅干？

3）Cookie的使用由瀏覽器根據(jù)一定的原則在后臺自動發(fā)送到服務器。瀏覽器檢查所有存儲的cookies。如果cookie的聲明范圍大于或等于要請求的資源的位置，則cookie將附加到要請求的資源的HTTP請求頭并發(fā)送到服務器。這意味著麥當勞的會員卡只能在麥當勞的商店里出示。如果分店還自行發(fā)放會員卡，進入店內(nèi)時，不僅要出示麥當勞的會員卡，還要出示店內(nèi)的會員卡。

了解cookie的機制后，我們可以在后臺代碼中引入httpclient類庫來操作cookie對象。

如果客戶端支持Cookie，則當web服務器返回響應時，它會在響應頭uName=XXXX“頭屬性中添加一個“set Cookie:Cookie”，將Cookie發(fā)送到響應中的客戶端。

客戶端將cookie存儲在本地文件中。下次訪問web服務器時，它將把cookie信息放入HTTP請求的“cookie”頭屬性中。這樣，jsessionid將與HTTP請求一起返回到web服務器。

假設我拿到了別的用戶的淘寶網(wǎng)站的cookie，我放到自己的http請求里，我就可以冒充這個用戶嗎？

理論上，如果你得到一個cookie，你就可以模擬一個用戶。根據(jù)以下具體分析：

此“身份密碼”由服務器生成并放置在客戶端瀏覽器的cookie中。服務器將有一個與之對應的會話，會話ID也存儲在cookie中。

如上所述，服務器的會話ID存儲在客戶端的cookie中，以便其他用戶在cookie中獲得會話ID后，可以模擬原始用戶啟動請求。

這似乎不合理

！但是，這是cookies和會話的機制。我們說過當cookie被禁用后，session可能無法正常工作，但是我們可以通過get將sessionid傳遞給服務器，因此如果sessionid以明文形式傳輸，則存在安全風險。

由于cookie存儲在客戶機中并且不安全，因此當我們將用戶數(shù)據(jù)存儲在cookie中時，我們將對其進行加密。例如，它將驗證用戶的IP、終端身份等，即使其他用戶偽造Cookie，也無法驗證。

移動端開發(fā)為什么不采用session而是用token？

事實上，令牌和會話不是同一個域概念。令牌是字符串，而會話是會話。兩者并不沖突或相互替代。

這里我要說的是令牌和會話ID之間的區(qū)別（通常在cookie中）。

令牌本身是由OAuth系列在大規(guī)模普及之前引入的。主要目的是支持sso，即單點登錄，這是OAuth系列的主要需求。當然，一些基于cookie/會話的框架（比如jasigcas）可以支持sso，但是它們沒有OAuth那么簡潔。OAuth使用token作為唯一的證書，第三方服務器在驗證token后可以建立自己的會話（廣義上說，在redis中可以同時使用傳統(tǒng)會話和token作為密鑰），并將用戶認證完全委托給OAuth。因此，分工相對明確，成為眾多商家共享用戶資源建立自己生態(tài)系統(tǒng)的首選。

傳統(tǒng)的會話管理很難實現(xiàn)這些目標。