UltKit

JWT-dekodeerder

Plak 'n JSON Web Token en lees die header en payload as geformateerde JSON, met die vervaltyd en uitreiktyd as datums en 'n aanduiding of die token tans geldig is. Die dekodering gebeur heeltemal in u blaaier, wat belangrik is wanneer die token 'n aktiewe toegangsbewys is.

0 karakters · 0 woorde · 0 reëls

0 karakters · 0 woorde · 0 reëls

Werk heeltemal in hierdie blaaieroortjie. Jou teks word nooit opgelaai of gestoor nie.

Geregistreerde eise

Die sewe eisname gedefinieer in RFC 7519 §4.1. Almal is opsioneel; tye is sekondes sedert 1970-01-01 UTC.

EisBetekenis
issUitreiker: wie die teken geskep en onderteken het
subOnderwerp: die gebruiker of entiteit waaroor die teken gaan
audTeikengehoor: vir wie die teken bedoel is
expVervaltyd: verwerp die teken ná hierdie oomblik
nbfNie voor nie: verwerp die teken voor hierdie oomblik
iatUitgereik op: wanneer die teken geskep is
jtiJWT-ID: unieke identifiseerder, gebruik om herspeel te voorkom

Algemene alg-waardes

alg-waardeBetekenis
HS256HMAC met SHA-256; een gedeelde geheim onderteken en verifieer
RS256RSA PKCS#1 v1.5-handtekening met SHA-256; private sleutel onderteken, publieke sleutel verifieer
PS256RSA-PSS met SHA-256
ES256ECDSA op die P-256-kromme met SHA-256; kort handtekeninge
EdDSAEd25519- of Ed448-handtekeninge
noneOngetekende teken; bedieners moet dit verwerp

Wat binne 'n JSON Web Token is

JWT word in RFC 7519 (Mei 2015) gedefinieer, wat voorstel dat dit soos die Engelse woord "jot" uitgespreek word. Die gewone ondertekende vorm bestaan uit drie Base64url-stringe wat met punte verbind word: header.payload.signature. Die header noem die ondertekeningsalgoritme in alg, soos HS256 of RS256, en dikwels 'n sleutel-ID in kid. Die payload bevat eise (claims), JSON-velde soos sub (die gebruiker), iss (die uitreiker), aud (die beoogde teikengehoor) en exp, nbf en iat, wat tye in sekondes sedert 1 Januarie 1970 UTC is. Die dekodeerder skakel hierdie drie om na jou plaaslike tyd en ISO 8601, en sê vir jou of die token verval het, nog nie geldig is nie, of binne sy geldigheidsvenster val.

Base64url is 'n enkodering, nie enkripsie nie, so enigiemand wat 'n token het, kan die payload presies soos hierdie bladsy lees. Moet nooit wagwoorde, kaartnommers of ander geheime in eise sit nie. 'n Token met vyf dele wat deur punte geskei word, is 'n JWE, 'n geënkripteerde token; die inhoud daarvan kan nie sonder die sleutel gelees word nie, en die dekodeerder sê dit. 'n Voorste "Bearer " wat uit 'n Authorization-header gekopieer is, word outomaties verwyder.

Waarom die handtekening nie hier geverifieer word nie

Die handtekening bewys dat die header en payload deur iemand met die sleutel geskep is en sedertdien nie verander is nie. Om dit na te gaan, het jy daardie sleutel nodig: die gedeelde geheim vir HMAC-algoritmes soos HS256, of die uitreiker se publieke sleutel vir RS256, ES256 of EdDSA. Dit is 'n slegte idee om 'n produksie-ondertekeningsgeheim in enige webblad te plak, en 'n dekodeerder wat voorgee om vir 'n token in te staan sonder sleutel sou valse gerustheid gee, so hierdie gereedskap wys die handtekening maar verifieer dit nie. Beskou wat jy sien as 'n bewering wat die token maak, nie as feit nie.

Verifikasie hoort op jou bediener, met 'n onderhoude biblioteek en die verwagte algoritme vasgepen. Twee historiese foute verduidelik hoekom: om alg "none" te aanvaar, wat enigiemand toelaat om 'n ongetekende token te vervals, en algoritmeverwarring, waar 'n bediener wat RS256 verwag, mislei word om 'n HS256-handtekening te kontroleer met die publieke sleutel as die HMAC-geheim. 'n Dekodeerder is vir ontfouting: om te sien watter eise 'n verskaffer uitreik, 'n verkeerde aud raak te sien, of uit te vind dat 'n sessie misluk het omdat exp 'n minuut gelede verstryk het. Om die Base64url-segmente rou te lees, gebruik die Base64-dekodeerder.

Gereelde vrae

Is dit veilig om 'n regte toegangstoken in 'n JWT-dekodeerder te plak?
Op hierdie bladsy verlaat die token nooit jou blaaier nie. Tog werk 'n geldige token soos 'n wagwoord totdat dit verval, so verkies verstreke of toetstokens en hou lewendige tokens uit skermkiekies en geselsies.
Waarom wys my token as verval terwyl dit pas uitgereik is?
Kontroleer eers jou toestel se horlosie. Sommige uitreikers gee toegangstokens 'n leeftyd van net 'n paar minute, en 'n token wat uit 'n log gekopieer is, kan ouer wees as wat dit lyk. 'n exp wat in millisekondes eerder as sekondes geskryf is, doen die teenoorgestelde en beland duisende jare in die toekoms.
Kan iemand die payload van my JWT verander?
Hulle kan dit wysig en weer enkodeer, maar die handtekening sal nie meer pas nie. 'n Bediener wat handtekeninge met die regte sleutel en algoritme verifieer, verwerp die gewysigde token.
Wat is die verskil tussen JWS en JWE?
'n JWS (RFC 7515) is ondertekend, het drie dele en enigiemand kan dit lees. 'n JWE (RFC 7516) is geënkripteer, het vyf dele en net die sleutelhouer kan die payload lees.
Maak afmelding 'n JWT ongeldig?
Nie op sigself nie. 'n Ondertekende JWT bly geldig tot exp, tensy die bediener 'n weieringslys hou of 'n sessierekord nagaan, en daarom kry toegangstokens gewoonlik kort leeftye.