跳到主要內容

手寫jwt驗證,實現java和node無縫切換

前言


前端時間和我寫了一個簡易用戶管理後台,功能其實很簡單,涉及到的技術棧有:vue+elementUI,java+spring MVC以及node+egg,數據庫用的mysql,簡單方便。


一開始是我是只負責前端,但是前端開發的的速度太快,老是沒事,加上他小子並沒有接觸過實戰的項目,又怕他出亂子,所以考慮我也寫一個後端,


開始考慮的是用python+django,但是還是在半途放棄了,因為總感覺Django不過靈活,使用起來非常彆扭,也可能是用scrapy寫爬蟲寫多了,難以理解django的框架設計,總是會把他想象成一個scrapy架構,也導致代碼寫的很亂,下面上一張scrapy架構圖。



所以最後考慮的用node,Express和Koa框架學習過node應該都知道,我以前也用過express(寫過一個小demo),但是給我的感覺這到像是一個只能有5年以上node開發經驗才能玩的轉的,因為express是非常的精簡的,安裝它后,會發現它幾乎不會為你提供任何編碼規範,也沒有約束你的框架應該怎麼設計,以至於新手下載完成后完全不知道自己應該幹嘛,甚至不知道直接的文件應該寫在哪,沒有框架本身的約定,標準的MVC模型有着千奇百怪的寫法,所以我覺得沒有一定的架構思想和經驗是很難駕馭的。


koa我並沒有直接的使用過,只是聽說是express的原班人馬打造的,中間件是基於洋蔥圈模型實現的。下面上一張圖洋蔥圈模型圖。



而是後來直接就接觸的egg,egg標語是"為企業級框架和應用而生",


廢話說的有點多了,重點是通一套前端代碼,開發了兩套後端代碼,功能是完全一致的,後端都實現了相應的jwt驗證功能,-->,密鑰都是我們約定好的固定值,但是最後發現一樣的密鑰,相同的數據,使用的jwt包不同產生的結果也不同,這也就導致兩端之間無法相互切換,每次切換必須從登陸重新開始,這不太符合邏輯,而且重要的是後面的安排有需要這樣的功能,無法做到無縫切換就直接導致實現不了下面的功能。


提綱內容



  • jwt實現原理

  • jwt未能解決的疑惑

  • base64和base64url


jwt實現原理


其實作為一個前端開發人員,jwt實現原理我是沒必要懂得的,但是如果你不限於此,這算是個必不可少的內容了吧。


先上一張圖。



圖中数字1是後端使用jwt工具包生成的token,通常是由三部分組成,也就是token中間的兩個"."將其分為三部分,第一部分對應的是右邊的数字2部分,然後依次對應。


這三部分分別是頭部、有效載荷、簽名。


頭部:alg是指說用到的算法,type當然是令牌類型


有效荷載:sub所簽發的用戶,name是簽發者的姓名,lat是這簽發時間,exp是指到期時間,當然還有一些其他的,這些數據都是非必要數據,實則只有exp可能有用,因為有效數據實際都是在data裏面,當然你也可以不這麼做。


簽名:前兩者都是通過base64url編碼過的,而非是算法加密的,所以幾乎是透明的。但是簽名是默認是通過hsa256算法加密的 ,加密的規則是:


HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
your-256-bit-secret
)

如何驗證token呢?那更加簡單了,就是用前端傳回來的token前兩部分和服務器存的秘鑰再次加密一次,然後做base64url處理和第三部分比較,一樣代表這個token是自己簽發的,不一樣代表是偽造的,完了過後再將有效載荷部分進行base64url反編碼,就得到exp,然後和當前時間比較是否過期。


jwt未能解決的疑惑


經過測試,發現三個問題。


1、 node和java使用對應的jwt工具包生成的token不相同,這裡是指在一系列參數完全相同的情況下。


2、 還發現用java生成的token在jwt官網解析時候輸入秘鑰結果的到的簽名和自己的簽名不一樣,但是node是一樣的,於是就產生了java工具包在輸入簽名的時候對密鑰進行了其他處理的想法,但是他並沒有找出做出來怎麼樣的處理,也就是說我們在生成簽名的時候根本就連密鑰都是不一樣的。


3、 不管是node還是java生成的token,我們用原來一模一樣的數據和一樣的算法公式都產生不了和工具包生成一樣的簽名,也就是可以懷疑在進行hsa256算法加密前確實對秘鑰進行處理了。


base64和base64url


base64就是一種二進制編碼方式,原理很簡單,先準備一個包含64個字符的數組:


['A','B','C',...'a','b','c',...'0','1','2',...'+','/']

然後對二進制數據進行處理,每三個字節一組,一共24bit,一個字節8bit嘛,然後再將24分為4組,每組正好6bit。6bit的話就剛好能表示64個字符。如果編碼字符不是3的倍數,就會剩下一個字節或者兩個字節,這個時候就在後面填充\x00,再在編碼末尾加上一個或者兩個=號。解碼的時候制動力去掉就好了。


base64url編碼就是將字符編碼成url能傳遞的參數,因為base64編碼會出現+號和/號,然後就會在url中出現問題,所以base64url其實就是將+和/分別變成-和_

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!



網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!



※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師"嚨底家"!!



※幫你省時又省力,新北清潔一流服務好口碑



※別再煩惱如何寫文案,掌握八大原則!



Orignal From: 手寫jwt驗證,實現java和node無縫切換

留言

這個網誌中的熱門文章

.NET Core前後端分離快速開發框架(Core.3.0+AntdVue)

.NET Core前後端分離快速開發框架(Core.3.0+AntdVue) 目錄 引言 時間真快,轉眼今年又要過去了。回想今年,依次開源發布了 Colder.Fx.Net.AdminLTE(254Star) 、 Colder.Fx.Core.AdminLTE(335Star) 、 DotNettySocket(82Star) 、 IdHelper(47Star) ,這些框架及組件都是本着以實際出發,實事求是的態度,力求提高開發效率(我自己都是第一個使用者),目前來看反響不錯。但是隨着前端和後端技術的不斷變革,尤其是前端,目前大環境已經是前後端完全分離為主的開發模式,在這樣的大環境和必然趨勢之下,傳統的MVC就顯得有些落伍了。在這樣的背景下,一款前後端分離的.NET開發框架就顯得尤為必要,由此便定了框架的升級目標: 前後端分離 。 首先後端技術的選擇,從目前的數據來看,.NET Core的發展遠遠快於.NET Framework,最簡單的分析就是Colder.Fx.Core.AdminLTE發布比Colder.Fx.Net.AdminLTE晚,但是星星卻後來居上而且比前者多30%,並且這個差距在不斷擴大,由點及面的分析可以看出我們廣大.NET開發人員學習的熱情和积極向上的態度,並不是某些人所認為的那麼不堪( 走自己的路,讓別人說去吧 )。大環境上微軟积極擁抱開源,大力發展.NET Core, 可以說前途一片光明。因此後端決定採用 .NET Core3.0 ,不再浪費精力去支持.NET Framework。 然後是前端技術選擇,首選是三大js框架選擇,也是從實際出發,Vue相對其它而言更加容易上手,並且功能也毫不遜色,深得各種大小公司喜歡,如果偏要說缺點的話,那就是對TS支持不行,但是即將發布Vue3.0肯定會改變這一缺陷。選擇了Vue之後,然後就是UI框架的選擇了,這裏的選擇更多了,我選擇了Ant Design Vue,理由便是簡潔方便,十分符合我的設計理念。 技術選型完畢之後便...