Struktura dhe funksionimi i një JSON Web Token (JWT)
Një JSON Web Token (JWT) është një standard i hapur (RFC 7519) që përdoret për transferimin e sigurt të informacionit midis dy palëve në formën e një objekti JSON. Ky informacion mund të verifikohet dhe të besohet sepse është i nënshkruar në mënyrë digjitale. Një token JWT përbëhet strukturor nga tri pjesë të ndara me pikë (.): koka (header), ngarkesa (payload) dhe nënshkrimi (signature).
Formati i përgjithshëm i një tokeni është:
koka.ngarkesa.nënshkrimi
Secila prej këtyre pjesëve është e koduar individualisht me Base64URL për të siguruar që të dhënat mund të transmetohen pa probleme në mjedise të ndryshme, si për shembull brenda kokave HTTP ose parametrave të URL-së. Vegla "Dekodues JWT" merr këtë varg karakteresh, ndan tri pjesët përbërëse dhe dekodon dy pjesët e para për të shfaqur përmbajtjen e tyre në formatin origjinal JSON.
Koka e JWT dhe pretendimet e saj (Claims)
Koka (header) e një JWT përmban informacion rreth llojit të tokenit dhe algoritmit të përdorur për sigurimin e tij. Kjo pjesë është e koduar në Base64URL dhe, pasi dekodohet, shfaqet si një objekt JSON. Brenda kokës gjenden disa pretendime (claims) standarde:
alg(Algoritmi): Përcakton algoritmin kriptografik që është përdorur për të nënshkruar tokenin, si për shembull HS256 (HMAC duke përdorur SHA-256) ose RS256 (RSA duke përdorur SHA-256).typ(Lloji): Specifikon llojin e tokenit, i cili në këtë rast është pothuajse gjithmonë "JWT".
Këto të dhëna ndihmojnë sistemet që pranojnë tokenin të kuptojnë se si duhet të trajtohet dhe verifikohet nënshkrimi i tij.
Ngarkesa e JWT dhe pretendimet kohore
Ngarkesa (payload) përmban pretendimet (claims) aktuale, të cilat janë deklarata rreth një subjekti (përdoruesit) dhe të dhënave shtesë. Këto pretendime ndahen në tri kategori: të rezervuara (standarde), publike dhe private. Pretendimet më të rëndësishme kohore që përcaktojnë jetëgjatësinë e tokenit janë:
iat(Issued At): Koha kur tokeni është lëshuar. Ky pretendim përfaqësohet si një vulë kohore Unix (numri i sekondave që nga 1 janari 1970).exp(Expiration Time): Koha kur tokeni skadon dhe nuk duhet të pranohet më për autorizim. Ashtu siiat, edhe ky pretendim shkruhet si vulë kohore Unix.
Nëse një token nuk përmban pretendimin exp, ai nuk ka një afat skadimi të përcaktuar brenda strukturës së tij.
Kodimi Base64URL dhe formati JSON
Një gabim i zakonshëm është ngatërrimi i dekodimit me enkriptimin. JWT-të standarde nuk janë të enkriptuara; ato janë thjesht të koduara. Kodimi Base64URL është një variant i Base64 që zëvendëson karakteret + me - dhe / me _, si dhe heq mbushjen me = në fund, në mënyrë që vargu të jetë i sigurt për t'u përdorur në URL.
Pasi kryhet dekodimi i Base64URL, të dhënat e përfituara duhet të jenë në formatin JSON (JavaScript Object Notation). JSON është një format i lehtë për shkëmbimin e të dhënave që lexohet lehtësisht nga njerëzit dhe makinat. Nëse koka ose ngarkesa nuk janë të strukturuara si JSON i vlefshëm pas dekodimit, tokeni konsiderohet i dëmtuar ose i krijuar gabim.
Dallimi midis dekodimit dhe verifikimit
Ekziston një ndryshim kritik sigurie midis dekodimit të një JWT dhe verifikimit të tij:
- Dekodimi: Ky proces thjesht përkthen vargun e koduar Base64URL përsëri në tekst të lexueshëm JSON. Kushdo që ka qasje te tokeni mund ta dekodojë atë pa pasur nevojë për ndonjë çelës sekret. Vegla "Dekodues JWT" kryen vetëm këtë proces. Ajo nuk verifikon nënshkrimin e JWT dhe nuk kërkon një sekret nënshkrimi apo çelës publik.
- Verifikimi: Ky proces vërteton nëse tokeni është ndryshuar gjatë rrugës. Ai kërkon përdorimin e algoritmit kriptografik të specifikuar në kokë dhe çelësin sekret ose publik përkatës për të llogaritur nënshkrimin dhe për ta krahasuar atë me nënshkrimin e pranishëm në token.
Mosverifikimi i nënshkrimit të një JWT në një mjedis prodhimi përbën një rrezik të madh sigurie, pasi sulmuesit mund të ndryshojnë ngarkesën (për shembull, të ndryshojnë rolin e përdoruesit në "admin") dhe të dërgojnë tokenin e modifikuar.
Rregullat e validimit dhe mesazhet e gabimit
Gjatë përpunimit të një tokeni, vegla zbaton rregulla të rrepta për të përcaktuar vlefshmërinë e formatit dhe shfaq mesazhe specifike gabimi nëse tokeni nuk është i rregullt:
- Nëse fusha e futjes së të dhënave është bosh, vegla qëndron në gjendjen "Gati. Ngjitni një JWT për ta dekoduar.".
- Nëse inputi nuk përmban saktësisht dy pika ndarëse, shfaqet gabimi: "Nuk është një JWT e vlefshme — priteshin tri pjesë të ndara me pikë.".
- Nëse koka nuk mund të dekodohet për shkak të një formati të gabuar Base64URL, shfaqet: "Nuk u mundësua dekodimi i kokës — Base64URL i pavlefshëm.".
- Nëse ngarkesa ka probleme të ngjashme kodimi, shfaqet: "Nuk u mundësua dekodimi i ngarkesës — Base64URL i pavlefshëm.".
- Nëse pas dekodimit koka nuk është një objekt i vlefshëm JSON, shfaqet: "Koka nuk është JSON i vlefshëm.".
- Nëse ngarkesa nuk është JSON i vlefshëm, shfaqet: "Ngarkesa nuk është JSON i vlefshëm.".
- Nëse vargu i futur tejkalon gjatësinë normale të një tokeni të arsyeshëm, shfaqet mesazhi: "Kjo është shumë e gjatë për të qenë një JWT e vërtetë.".
Kur futet një token i pavlefshëm, zonat e dekoduara fshihen automatikisht nga ekrani. Kur përdoruesi klikon butonin "Pastro", fusha e të dhënave zbrazet dhe fokusi i tastierës kthehet menjëherë te fusha e futjes së të dhënave.
Privatësia dhe përpunimi i të dhënave
Kur përdorni këtë vegël, privatësia e të dhënave tuaja është e mbrojtur pasi i gjithë procesi i dekodimit kryhet lokalish brenda shfletuesit tuaj të internetit. Tokeni juaj dekodohet në shfletuesin tuaj dhe asgjë nuk ngarkohet në BroBroGo. Kjo parandalon rrjedhjen e të dhënave të ndjeshme që mund të jenë të pranishme brenda ngarkesës së tokenit.
Pyetje të shpeshta (FAQ)
A është e sigurt të ngjis JWT-në time këtu?
Po. Dekodimi ndodh tërësisht në shfletuesin tuaj — tokeni juaj nuk dërgohet kurrë te BroBroGo.
A e verifikon kjo nënshkrimin?
Jo. Ai vetëm dekodon kokën (header) dhe ngarkesën (payload) që ju t'i lexoni. Verifikimi i një nënshkrimi kërkon sekretin e nënshkrimit ose çelësin publik, të cilin kjo vegël nuk e kërkon kurrë.
Si mund ta di nëse tokeni im ka skaduar?
Dekoduesi lexon pretendimin exp dhe tregon një distinktiv statusi — i vlefshëm, i skaduar, jo ende i vlefshëm ose pa skadim — pranë tokenit të dekoduar.
Çfarë ndodh nëse tokeni im nuk ka një pretendim "exp"?
Nëse një token nuk ka një pretendim exp në ngarkesën e tij, vegla do të shfaqë statusin "Pa skadim".