Ⅰ token和session和cookie的區別是什麼
一、表達意思不同
1、token：（某些機器中用以代替紙幣的）代幣，專用輔幣；象徵，標志；禮券，代金券；（語言學）符號；（計算機）令牌，記號；（火車通行的）路簽；裝點門面的，裝樣子的；象徵性的，作為標志的。
2、session：（某項活動的）一段時間，一場；（議會等的）會議，（法庭的）開庭；學年，上課時間；（酒吧中）演奏會（尤指演奏愛爾蘭音樂）；（尤指錄音師的）灌錄音樂時間；（音樂家）伴奏的。
3、cookie：曲奇餅，小甜餅；……樣的人；（瀏覽網頁後存儲在計算機的）緩存文件；<蘇格蘭>淡麵包；漂亮的年輕女子。
二、固定搭配不同
1、token：as a token of作為…的標志；by the same token同樣地；出於同樣原因。
2、session：session key會話密鑰；對話關鍵碼。
3、cookie：fortune cookie簽餅；福餅。
例句
1、Thepenalty forfailurewillbe high. But, by thesametoken, therewards forsuccesswillbe great.
失敗就要付出沉重的代價，同樣，成功就會獲得很大的回報。
2、It turnedout to beaveryinterestingsessionwith a livelydebate.
結果成了一次充滿激烈辯論、非常有意思的會議。
3、Onenightyoujusthave to haveacookieandyouknowthere .
有一天晚上，你就是需要吃一塊餅干，而你知道櫥櫃里有一袋你最喜歡的餅干。
Ⅱ 伺服器Token不存儲可以嗎,由客戶端每次帶上Token,客戶端各自存儲Token
Token是服務端生成的一串字元串，以作客戶端進行請求的一個令牌，當第一次登錄後，伺服器生成一個Token便將此Token返回給客戶端，以後客戶端只需帶上這個Token前來請求數據即可，無需再次帶上用戶名和密碼。
兩種使用方式：
用設備號/設備mac地址作為Token（推薦）
客戶端：客戶端在登錄的時候獲取設備的設備號/mac地址，並將其作為參數傳遞到服務端。
服務端：服務端接收到該參數後，便用一個變數來接收同時將其作為Token保存在資料庫，並將該Token設置到session中，客戶端每次請求的時候都要統一攔截，並將客戶端傳遞的token和伺服器端session中的token進行對比，如果相同則放行，不同則拒絕。
分析：此刻客戶端和伺服器端就統一了一個唯一的標識Token，而且保證了每一個設備擁有了一個唯一的會話。該方法的缺點是客戶端需要帶設備號/mac地址作為參數傳遞，而且伺服器端還需要保存；優點是客戶端不需重新登錄，只要登錄一次以後一直可以使用，至於超時的問題是有伺服器這邊來處理，如何處理看若伺服器的Token超時後，伺服器只需將客戶端傳遞的Token向資料庫中查詢，同時並賦值給變數Token，如此，Token的超時又重新計時。
用session值作為Token
客戶端：客戶端只需攜帶用戶名和密碼登陸即可。
客戶端：客戶端接收到用戶名和密碼後並判斷，如果正確了就將本地獲取sessionID作為Token返回給客戶端，客戶端以後只需帶上請求數據即可。
分析：這種方式使用的好處是方便，不用存儲數據，但是缺點就是當session過期後，客戶端必須重新登錄才能進行訪問數據。
Ⅲ token和sessionid的區別是什麼
cookie和session都是用來跟蹤瀏覽器用戶身份的會話方式。cookie與session的區別是，cookie數據保存在客戶端，session數據保存在伺服器端。簡單的說，當你登錄一個網站的時候，如果web伺服器端使用的是session,那麼所有的數據都保存在伺服器上面，客戶端每次請求伺服器的時候會發送當前會話的sessionid，伺服器根據當前sessionid判斷相應的用戶數據標志，以確定用戶是否登錄，或具有某種許可權。由於數據是存儲在伺服器上面，所以你不能偽造，但是如果你能夠獲取某個登錄用戶的sessionid，用特殊的瀏覽器偽造該用戶的請求也是能夠成功的。sessionid是伺服器和客戶端鏈接時候隨機分配的，一般來說是不會有重復，但如果有大量的並發請求，也不是沒有重復的可能性，我曾經就遇到過一次。登錄某個網站，開始顯示的是自己的信息，等一段時間超時了，一刷新，居然顯示了別人的信息。如果瀏覽器使用的是cookie，那麼所有的數據都保存在瀏覽器端，比如你登錄以後，伺服器設置了cookie用戶名(username),那麼，當你再次請求伺服器的時候，瀏覽器會將username一塊發送給伺服器，這些變數有一定的特殊標記。伺服器會解釋為cookie變數。所以只要不關閉瀏覽器，那麼cookie變數便一直是有效的，所以能夠保證長時間不掉線。如果你能夠截獲某個用戶的cookie變數，然後偽造一個數據包發送過去，那麼伺服器還是認為你是合法的。所以，使用cookie被攻擊的可能性比較大。如果設置了的有效時間，那麼它會將cookie保存在客戶端的硬碟上，下次再訪問該網站的時候，瀏覽器先檢查有沒有cookie，如果有的話，就讀取該cookie，然後發送給伺服器。如果你在機器上面保存了某個論壇cookie，有效期是一年，如果有人入侵你的機器，將你的cookie拷走，然後放在他的瀏覽器的目錄下面，那麼他登錄該網站的時候就是用你的的身份登錄的。所以cookie是可以偽造的。當然，偽造的時候需要主意，直接cookie文件到cookie目錄，瀏覽器是不認的，他有一個index.dat文件，存儲了cookie文件的建立時間，以及是否有修改，所以你必須先要有該網站的cookie文件，並且要從保證時間上騙過瀏覽器，曾經在學校的vbb論壇上面做過試驗，別人的cookie登錄，冒用了別人的名義發帖子，完全沒有問題。更有效的方法就是自己定義一個瀏覽器，我們稱之為黑客瀏覽器，比如我們可以自己改造firefox瀏覽器，可以自定義sessionid，自定義cookie值，那樣就可以隨心所欲了。網路安全又將面臨嚴峻的挑戰。--------------------------------------------------------------------------------兩個都可以用來存私密的東西，同樣也都有有效期的說法。區別在於。session是放在伺服器上的，過期與否取決於服務期的設定，cookie是存在客戶端的，過去與否可以在cookie生成的時候設置進去。1、cookie數據存放在客戶的瀏覽器上，session數據放在伺服器上2、cookie不是很安全，別人可以分析存放在本地的COOKIE並進行COOKIE欺騙考慮到安全應當使用session3、session會在一定時間內保存在伺服器上。當訪問增多，會比較佔用你伺服器的性能考慮到減輕伺服器性能方面，應當使用COOKIE4、單個cookie在客戶端的限制是3K，就是說一個站點在客戶端存放的COOKIE不能3K。5、300個的限制我沒聽說6、所以個人建議：將登陸信息等重要信息存放為SESSION其他信息如果需要保留，可以放在COOKIE中
Ⅳ bearer token 是什麼意思
一種令牌類型。Oauth2.0的官網有說明（OAuth 2.0 Bearer Token Usage）
RFC6749
RFC6750
Bearer Type Access Token：
BEARER類型的token是在RFC6750中定義的一種token類型，OAuth2.0協議RFC6749對其也有所提及，算是對RFC6749的一個補充。BEARER類型token是建立在HTTP/1.1版本之上的token類型，需要TLS（Transport Layer Security）提供安全支持，該協議主要規定了BEARER類型token的客戶端請求和服務端驗證的具體細節。
MAC Type Access Token：
前面介紹了BEARER類型的token，RFC6750明確說明該類型token需要TLS（Transport Layer Security）提供安全支持。雖然現今大部分站點都已經或正在由HTTP向HTTPS遷移，但是仍然會有站點繼續在使用HTTP，在這類站點中BEARER類型的token存在安全隱患，這個時候MAC類型的token正是用武之地，MAC類型的token設計的主要目的就是為了應對不可靠的網路環境。
MAC類型相對於BEARER類型對於用戶資源請求的區別在於，BEARER類型只需要攜帶授權伺服器下發的token即可，而對於MAC類型來說，除了攜帶授權伺服器下發的token，客戶端還要攜帶時間戳，nonce，以及在客戶端計算得到的mac值等信息，並通過這些額外的信息來保證傳輸的可靠性。
其實很多API服務並沒有使用https加密連接（卻使用了BEARER類型的token），所以你可以利用一些抓包工具進行抓包分析，可以看到一些應用請求附帶的token，你拿這個token也可以訪問相應的第三方api，可能有的token時效比較短，用不了多久就會過期。
Ⅳ Token Cookie和Session的區別
Cookie
cookie 是一個非常具體的東西，指的就是瀏覽器裡面能永久存儲的一種數據，僅僅是瀏覽器實現的一種數據存儲功能。
cookie由伺服器生成，發送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內，下一次請求同一網站時會把該cookie發送給伺服器。由於cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會占據太多磁碟空間，所以每個域的cookie數量是有限的。
Session
session 從字面上講，就是會話。這個就類似於你和一個人交談，你怎麼知道當前和你交談的是張三而不是李四呢？對方肯定有某種特徵（長相等）表明他就是張三。
session 也是類似的道理，伺服器要知道當前發請求給自己的是誰。為了做這種區分，伺服器就要給每個客戶端分配不同的「身份標識」，然後客戶端每次向伺服器發請求的時候，都帶上這個「身份標識」，伺服器就知道這個請求來自於誰了。至於客戶端怎麼保存這個「身份標識」，可以有很多種方式，對於瀏覽器客戶端，大家都默認採用 cookie 的方式。
伺服器使用session把用戶的信息臨時保存在了伺服器上，用戶離開網站後session會被銷毀。這種用戶信息存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web伺服器做了負載均衡，那麼下一個操作請求到了另一台伺服器的時候session會丟失。
Token
token的意思是「令牌」，是用戶身份的驗證方式，最簡單的token組成:uid(用戶唯一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以哈希演算法壓縮成一定長的十六進制字元串，可以防止惡意第三方拼接token請求伺服器)。還可以把不變的參數也放進token，避免多次查庫
Ⅵ 什麼是Http無狀態Session、Cookie、Token三者之間的區別
HTTP無狀態協議，是指協議對於交互性場景沒有記憶能力。
在點擊一個純的html網頁，請求獲取伺服器的html文件資源時，每次http請求都會返回同樣的信息，因為這個是沒有交互的，每一次的請求都是相互獨立的。第一個請求和第二個請求也沒有先後順序，返回處理哪個，結果都是同樣的資源頁面，因為這種場景是無交互的，無論是什麼人請求這個地址，伺服器都是返回那個相同的響應。
在無交互場景中上面那樣，當然也不會有太大的問題。但是對於涉及到動態交互的場景，就顯得很尷尬了，何為交互？有來又有往，對於一模一樣的兩個介面，不同的人在請求第二個介面時可能會基於請求第一個介面的結果而有所不同。
現在我們來想一個復雜的場景，如在購物網站上買一個書包，流程如下：
所謂的登錄只是驗證你是否是一個合法用戶，若是合法則跳轉到信息的頁面，不合法則告知用戶名密碼錯誤。
但是我們在第一步給伺服器發完/login介面後，伺服器就忘記了。。。忘記了你這個人，到底有沒有經過認證。
所以在添加商品時/cart 你還是需要將你的賬號密碼和商品信息一起提交給 addCart介面，再讓伺服器做驗證。
第三步同理。
所以當我們說涉及到交互時，情形就完全不一樣了，因為這三步是有依賴關系的，第一步驗證登錄者是一個合法用戶，驗證通過給你返回200/OK，但是只要伺服器給返回了響應，那麼一個http的請求和響應就結束了。伺服器怎麼知道10秒鍾之前你剛剛登錄過呢？不好意思，伺服器不知道你有沒有登陸過，他只是對外提供一個登錄介面，要想證明你是合法用戶必須調/login介面。
第二步，將商品加入到購物車中時，你會調用/cart介面，但是注意，這個行為是和第一步是有關聯關系的，是誰將什麼物品加入到購物車中了？這個誰，有沒有在網站上注冊賬號呢，是不是一個合法用戶呢？所以說在添加購物車的時候，我們還需要將賬號密碼再次加入到請求參數中，每做一次操作購物車操作時，都需要再把之前已經傳輸過的賬號密碼，再反反復復的傳輸一遍又一遍，這是因為伺服器不知道你是不是在20秒之前剛登陸過。
上面的無狀態是指的，無登錄狀態，即伺服器不知道某個用戶是否已登錄過了。因為愚蠢的伺服器不知道客戶端是否已登錄過了,所以每次都要在交互場景(會話)中請求中帶上上一次的請求信息，如賬號、密碼。明明只需要在/login介面中，才需要對比資料庫中的賬號密碼和客戶端傳的是否一致來確定合法性。這下在添加購物車中也需要再一次地進行同樣的重復且沒有必要的操作，即降低了響應速度，又對用戶不友好(因為每次都需要填賬號，密碼)。
缺少狀態意味著如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另外人們常說的「會話」概念則是上面的交互行為的另一種表述方式。
通過上面我們知道了Http中無狀態是一個什麼概念，以及在無狀態情況下，要進行添加購物車功能，所帶來的困難。
客戶端與伺服器進行動態交互的Web應用程序出現之後，HTTP無狀態的特性嚴重阻礙了這些應用程序的實現，畢竟交互是需要承前啟後的，簡單的購物車程序也要知道用戶到底在之前選擇了什麼商品。於是，兩種用於保持HTTP連接狀態的技術就應運而生了，一個是Cookie，而另一個則是Session。HTTP本身是一個無狀態的連接協議，為了支持客戶端與伺服器之間的交互，我們就需要通過不同的技術為交互存儲狀態，而這些不同的技術就是Cookie和Session了。
由於HTTP是一種無狀態的協議，伺服器 單純從網路連接上 無從知道客戶身份。怎麼辦呢？就給客戶端們頒發一個通行證吧，每人一個，無論誰訪問都必須攜帶自己的通行證。這樣伺服器就能從通行證上確認客戶身份了。這就是Cookie的工作原理。
Cookie實際上是一小段的文本信息。客戶端請求伺服器，如果伺服器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie。客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時， 瀏覽器把請求的網址連同該Cookie一同提交給伺服器 。伺服器檢查該Cookie，以此來辨認用戶狀態。伺服器還可以根據需要修改Cookie的內容。
很多網站都會使用Cookie。例如，Google會向客戶端頒發Cookie，Bai也會向客戶端頒發Cookie。那瀏覽器訪問Google會不會也攜帶上Bai頒發的Cookie呢？或者Google能不能修改Bai頒發的Cookie呢？
答案是否定的。Cookie具有不可跨域名性。根據Cookie規范，瀏覽器訪問Google只會攜帶Google的Cookie，而不會攜帶Bai的Cookie。Google也只能操作Google的Cookie，而不能操作Bai的Cookie。
Cookie在客戶端是由瀏覽器來管理的。瀏覽器能夠保證Google只會操作Google的Cookie而不會操作Bai的Cookie，從而保證用戶的隱私安全。瀏覽器判斷一個網站是否能操作另一個網站Cookie的依據是域名。Google與Bai的域名不一樣，因此Google不能操作Bai的Cookie。
1.在登錄網站的時候選擇記住密碼
2.點擊之後觀察伺服器上的相應內容
3.查看Chrome中的Cookie設置
4.觀察伺服器返回的Cookie內容
5.再次訪問時，發現不需要輸入密碼即可直接登錄，觀察請求頭信息
cookie並不是單純為了實現 session機制而生的。而是1993 年，網景公司雇員 Lou Montulli 為了讓用戶在訪問某網站時，進一步提高訪問速度，同時也為了進一步實現個人化網路，發明了今天廣泛使用的 Cookie。cookie還有一個很廣泛的用途就是記住用戶的登錄賬號和密碼，這樣當用戶以後再次需要登錄同一個網站或系統的時候就不需要再次填寫這兩個欄位而是直接點擊「登錄」按鈕就好。這就相當於給了一些「甜頭」給用戶，這就回應了「cookie」這個詞語的字面意思了。
實現方法是把登錄信息如賬號、密碼等保存在Cookie中，並控制Cookie的有效期，下次訪問時再驗證Cookie中的登錄信息即可。
我是 「翎野君」 ，感謝各位朋友的： 點贊 、 收藏 和 評論 ，我們下期見。
Ⅶ 哪些用不了session ,必須得用token的
比如現在人們常用的購物app軟體。
session和token都是用來保持會話，功能相同。session是服務端存儲的一個對象，主要用來存儲所有訪問過該服務端的客戶端的用戶信息（也可以存儲其他信息），從而實現保持用戶會話狀態。但是伺服器重啟時，內存會被銷毀，存儲的用戶信息也就消失了。token適用於項目級的前後端分離（前後端代碼運行在不同的伺服器下）
其實token和session不是同一個領域的概念。token是一個字元串，而session是指一個會話，兩者既不沖突又不可互相替代。
Ⅷ h5頁面在微信上登錄不保存token
可以通過localStorage來實現。
localStorage會可以將第一次請求的數據直接存儲到本地，這個相當於一個5M大小的針對於前端頁面的資料庫，相比於cookie可以節約帶寬就可以了。
localStorage與sessionStorage的唯一一點區別就是localStorage屬於永久性存儲，而sessionStorage屬於當會話結束的時候，sessionStorage中的鍵值對會被清空。
Ⅸ 前後端分離為什麼不用session來保存登錄狀態，用 token based 驗證 用意何在
後端伺服器有兩種基本的身份驗證：
是基於Cookie的身份驗證，使用伺服器端的cookie來對每次請求的用戶進行身份驗證。
較新的方法，基於令牌Token-Based的認證，依賴於被發送到伺服器上每個請求的簽署令牌。
為什麼基於令牌token-based的方式更好呢？理由如下：
跨域/CORS:cookies+CORS並不能跨不同的域名.而基於令牌能夠使用AJAX調用伺服器，在任何域名下你都可以使用HTTPheader頭部來傳輸用戶信息。
無態(代表伺服器端可伸縮):沒有必要將會話保存，令牌token自己是一個自我包容的實體，包含用戶各種信息，其他狀態信息可以保存在cookie或客戶端本地存儲器中
CDN:能夠適用來自CDN任何應用部件(e.g.javascript,HTML,images,etc.),你的伺服器只是一個API.
解耦:你不必和一個特定的驗證格式Schema綁定，令牌token能在任何地方產生，這樣的你的API可以在任何地方以同一種驗證方式調用驗證。
對移動Mobile友善:當你在一個原生平台(iOS,Android,Windows8,etc.)時，cookies依賴於一個安全API，並不是好主意，因為你得和一個cookie容器打交道，而基於令牌則簡單多。
CSRF:因為你不依賴cookies,你就不需要跨請求保護，(e.g.it有可能來自<iframe>請求一個POST，需要重用一個存在的驗證。).
.性能:一個網路往返（如發現在資料庫中的會話）可能會比計算的HMACSHA256驗證令牌耗費更多時間。
登錄頁面不是一個特殊情況，如果你如果您正在使用量角器來寫你的功能測試，你不需要來處理登錄的任何特殊情況。
基於標准:你的API能接受一個標準的JSONWebToken(JWT).這個標准後面有多個庫包(.NET,Ruby,Java,Python,PHP)，許多公司支持(e.g.Firebase,Google,Microsoft).，比如Firebase允許他們的客戶使用任何身份驗證機制，只要你使用預先定義的屬性生成一個JWT，並使用共享密鑰簽署，就能調用它們的API.
Ⅹ token是什麼意思
是計算機術語：令牌，令牌是一種能夠控制站點佔有媒體的特殊幀，以區別數據幀及其他控制幀。token其實說的更通俗點可以叫暗號，在一些數據傳輸之前，要先進行暗號的核對，不同的暗號被授權不同的數據操作。基於
Token
的身份驗證方法
使用基於
Token
的身份驗證方法，在服務端不需要存儲用戶的登錄記錄。大概的流程是這樣的：
1.客戶端使用用戶名跟密碼請求登錄
2.服務端收到請求，去驗證用戶名與密碼
3.驗證成功後，服務端會簽發一個
Token，再把這個
Token
發送給客戶端
4.客戶端收到
Token
以後可以把它存儲起來，比如放在
Cookie
里或者
Local
Storage
里
5.客戶端每次向服務端請求資源的時候需要帶著服務端簽發的
Token
6.服務端收到請求，然後去驗證客戶端請求裡面帶著的
Token，如果驗證成功，就向客戶端返回請求的數據