色色一区二区三区,一本大道道久久九九AV综合,国产香蕉97碰碰视频va碰碰看,综合亚洲国产2020

    <legend id="mljv4"><u id="mljv4"><blockquote id="mljv4"></blockquote></u></legend>

    <sub id="mljv4"><ol id="mljv4"><abbr id="mljv4"></abbr></ol></sub>
      <mark id="mljv4"></mark>
      人文藝術(shù) > APP服務(wù)端接口,用jwt還是用redis和token,分別有什么優(yōu)勢?

      APP服務(wù)端接口,用jwt還是用redis和token,分別有什么優(yōu)勢?

      2020-07-26 07:19閱讀(205)

      APP服務(wù)端接口,用jwt還是用redis和token,分別有什么優(yōu)勢?:jwt屬于無狀態(tài)設(shè)計,用戶登陸的信息關(guān)鍵存放在jwt加密數(shù)據(jù)里,這種設(shè)計下服務(wù)器不需要存儲jwt密文,

      1

      jwt屬于無狀態(tài)設(shè)計,用戶登陸的信息關(guān)鍵存放在jwt加密數(shù)據(jù)里,這種設(shè)計下服務(wù)器不需要存儲jwt密文,只需要解密就能拿到授權(quán)信息等用戶信息。這種設(shè)計是一種利用計算力減少token設(shè)計下數(shù)據(jù)庫及緩存的壓力和設(shè)計復(fù)雜度,因此它的本質(zhì)就是不存儲登陸授權(quán),而通過密文本身保存授權(quán)信息。

      token加redis設(shè)計,是一種登陸后分配隨機token,然后記錄token與用戶信息對應(yīng)關(guān)系的設(shè)計。

      很明顯,這兩張設(shè)計的區(qū)別就在于token實際上是需要服務(wù)器存儲,每次驗權(quán)需要查詢數(shù)據(jù)庫。jwt不需要服務(wù)器存儲,信息本身就存儲于jwt本身,這種模式無需使用數(shù)據(jù)庫。

      但是這種流行的jwt有一個設(shè)計上的缺陷,他通過密文傳輸用戶信息,那么服務(wù)器在這種基礎(chǔ)結(jié)構(gòu)下是無法做到關(guān)閉用戶登陸授權(quán)的操作,如果用戶的jwt密文被偷竊,那么黑客就能以用戶身份登陸,并且即使知道密文丟失,也無法關(guān)閉被偷竊的jwt密文。為了應(yīng)對這一問題,可以使用jwt內(nèi)部驗證有效期和jwt黑名單模式,但是有效期始終無法做到及時停止jwt授權(quán),這是一個治標(biāo)不治本的方法。而jwt黑名單模式,則需要數(shù)據(jù)庫或內(nèi)存存儲黑名單,那么,這實際上違背了jwt的免數(shù)據(jù)庫設(shè)計原則。

      因此,如果嚴(yán)格按照兩種模式設(shè)計,jwt更適合低安全級別的服務(wù)器設(shè)計,如普通的博客、閱讀器等等,這種服務(wù)允許不嚴(yán)格的登陸授權(quán),即使密文丟失也不會造成用戶的嚴(yán)重損失,卻能獲得較高的服務(wù)性能。

      token模式,必須配合數(shù)據(jù)庫進行存儲和查詢,因此性能較低,但token模式卻能做到及時的授權(quán)關(guān)閉,已經(jīng)登陸授權(quán)可見可查,每一次token都會有對應(yīng)的記錄。因此token模式適合較高安全度和用戶登陸等信息分析的系統(tǒng),如政府系統(tǒng),支付系統(tǒng)等不可能允許高權(quán)限的token被偷竊卻不能及時關(guān)閉授權(quán)。

      jwt,適合輕量的系統(tǒng)和權(quán)限不嚴(yán)格系統(tǒng)。

      token,適合重量系統(tǒng)和權(quán)限有嚴(yán)格要求的系統(tǒng)。


      謝謝大家的閱讀和頭條的推薦,我再來詳細的和大家討論下這兩者在實現(xiàn)上的區(qū)別,這樣大家可能更方便的理解這兩個不同的概念。

      我們討論的這兩種方式只限于規(guī)范實現(xiàn),如果有其他優(yōu)化或者衍生設(shè)計模式則不在討論之內(nèi)。

      token:

      普通的token方式采用的是:登錄-->生成隨機字符串(token)-->服務(wù)器保存token與用戶信息的對應(yīng)關(guān)系

      對應(yīng)用戶利用token校驗的流程是 token-->查詢token對應(yīng)用戶信息-->各系統(tǒng)根據(jù)用戶信息進行業(yè)務(wù)處理。


      很明顯可以看出,token模式下的字符串實際上不需要和用戶信息有任何關(guān)聯(lián),生成的token字符串的要求就是唯一,不能被其他用戶占有,否則就會出現(xiàn)用戶登錄后實際上是以其他人身份進行業(yè)務(wù)處理。如果字符串是隨機生成,那么黑客就無法猜測token的生成規(guī)律,也無法從token直接猜測到用戶相關(guān)信息。


      jwt:

      jwt采用的生成:登錄-->生成帶有用戶數(shù)據(jù)的加密字符串(該字符串服務(wù)器并不存儲,直接下發(fā)給客戶端)

      校驗:客戶端將存儲的jwt密文帶上-->服務(wù)器解密密文,獲取到用戶信息


      可以看出,jwt的憑證不僅要求唯一,還要求密文本身實際上是帶有了用戶信息,當(dāng)然這塊可以是非敏感信息,這只是實現(xiàn)上的細節(jié)區(qū)別,和結(jié)構(gòu)本身沒有特別大的關(guān)聯(lián)。服務(wù)器本身并沒有存儲這次jwt密文,每次服務(wù)器的處理都是直接解密jwt密文。這樣做的好處就是服務(wù)架構(gòu)內(nèi)直接拋棄了登錄相關(guān)的傳統(tǒng)token系統(tǒng),并且服務(wù)器不再管理登錄狀態(tài),token有效狀態(tài)等問題。

      而jwt帶來的問題,憑證實際上的一串密文,更多的用戶信息或session信息需要更大的密文來存儲,進而每次請求都帶上jwt就會使網(wǎng)絡(luò)傳輸?shù)膬?nèi)容變大,加大了網(wǎng)絡(luò)開銷;憑證是一串密文,那么如果黑客破解了服務(wù)器的加密方式,那么密文實際上就是用戶信息在網(wǎng)絡(luò)上傳輸,黑客可以直接偽造jwt登錄或通過jwt密文獲取到用戶信息;jwt本身不管理jwt的有效性,一旦密文被偷竊,無法做到關(guān)閉掉黑客的授權(quán)。

      2

      謝邀。


      什么是JWT

      JWT(Json Web Token),是為了在網(wǎng)絡(luò)應(yīng)用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開放標(biāo)準(zhǔn)。由頭部(Header)、負載(Payload)、簽名(Signature)三部分構(gòu)成,其中每一部分使用Base64編碼處理。

      Header 中存儲了所使用的加密算法和 Token 類型。

      Payload是負載,JWT 規(guī)范規(guī)定了一些字段,并推薦使用,當(dāng)然每一個開發(fā)者也可以自己指定字段和內(nèi)容。需要注意的是,該部分內(nèi)容只經(jīng)過了 Base64 編碼,相當(dāng)于明文存儲,所以不要放置敏感信息。

      而Signature,則是使用Base64編碼后的Header 和Payload以及一個秘鑰,使用header中指定簽名算法進行簽名。

      可用下面的圖對上述概念進行總結(jié):

      JWT的優(yōu)點&問題

      JWT屬于無狀態(tài),不依賴Cookie,可以在禁用Cookie的瀏覽器中運行,可有效防止CSRF攻擊;服務(wù)端不用存儲session,易于擴展;相比XML更加簡潔,更加適合在HTTP環(huán)境中傳輸。

      那么JWT都存在哪些問題呢?主要集中在以下幾個方面

      • 無法作廢已頒布的Token,比如說用戶注銷這個功能,傳統(tǒng)的基于session的方案,只需在服務(wù)端刪除該session即可,因為狀態(tài)在服務(wù)端存儲。而JWT就比較難辦到,因為JWT是無狀態(tài)的,存儲在客戶端,即使被刪除了,一定有效期內(nèi)服務(wù)端并不知道,它仍然是有效的。

      • 無法應(yīng)對過期的數(shù)據(jù)

      • 安全機制不夠高

      JWT適用場景

      • Restful API無狀態(tài)驗證

      • 一次性驗證:比如用戶注冊某網(wǎng)站后需要發(fā)送一封郵件讓其激活賬戶,通常該郵件中包含一個鏈接,該鏈接往往含有以下幾個特點:能夠標(biāo)識唯一用戶、不能被篡改、具有時效性。

      Redis & Token

      自己生成一個32位的key,value為用戶信息,客戶端訪問時服務(wù)端首先判斷Redis里是否有該Token,如果有,則加載該用戶信息完成登錄。服務(wù)需要存儲下發(fā)的每個token及對應(yīng)的value,維持其過期時間。

      本文為作者“一個程序員的奮斗史”問答原創(chuàng)文章,未經(jīng)允許轉(zhuǎn)載、抄襲必究!

      3

      jwt是生成和校驗解密token的工具,redis是緩存,他們之間并不沖突,加起來一起用效果更好,僅僅用token是不夠的,因為一但設(shè)置token意味著其登錄過期時間也就確定了。就無法讓其在有效期內(nèi)失效,這樣不合理的。。所以可以通過redis記錄token,控制其的有效性,和記錄一些信息。所以 token加redis才是正確的選擇。

      4

      都可以,通常情況下正式點我會用shiro+redis實現(xiàn)權(quán)限session認證管理,免去了自己實現(xiàn)session認證的過程,并且它還提供了一些進階的功能。簡陋點的話,redis+token就可以了,要自己去設(shè)計實現(xiàn),通常配合攔截器實現(xiàn)session認證。

      5

      Jwt是帶有簽名的客戶身份令牌。安全性還是比較高的。但是需要正確使用。它本身主要是證明客戶身份,并不包含機密信息。如果需要避免重復(fù)使用,可以提供時間戳,可以一次性使用。這樣很多安全問題就都解決了,F(xiàn)在很多服務(wù)都使用jwt認證。

      6

      問題很不專業(yè),jwt本質(zhì)上就是token,另外關(guān)redis什么事情?完全不是一類好嗎?同時使用jwt和redis的都很多

      7

      倆者沒有沖突啊,JWT的話APP內(nèi)部程序就可以直接驗證JWT是否合法,redis就是一個存儲而已,倆者結(jié)合才是真的

      相關(guān)問答推薦