JWT-dekooderi ja vanhentumislaskin

JWT-dekooderi ja vanhentumislaskin jäsentää JSON Web Tokens (JWT, määritelty RFC 7519:ssä) – vakiomuotoinen tilattomaan todennusmuotoon nykyaikaisissa verkkosovellusliittymissä. Se purkaa base64url-koodatun otsikon ja hyötykuorman, jäsentää JSON-vaatimukset ja analysoi aikaperusteisia vaatimuksia, mukaan lukien vanheneminen (exp), myönnetty (iat), ei ennen (nbf), aihe (sub), myöntäjä (iss) ja yleisö (aud). JWT:itä käyttävät OAuth2/OIDC-palveluntarjoajat (Auth0, Okta, AWS Cognito, Clerk, Firebase Auth, Supabase) ja useimmat nykyaikaiset istuntojärjestelmät. JWT koostuu kolmesta base64url-koodatusta segmentistä, jotka on erotettu pisteillä: header.payload.signature. Otsikko ilmoittaa allekirjoitusalgoritmin (HS256, RS256, ES256 ovat yleisiä). Hyötykuorma sisältää "vaatimukset" - sekä vakiovaatimukset (sub, exp, iat, nbf, iss, aud, jti) että mukautettuja sovelluskohtaisia ​​tietoja. Allekirjoitus sitoo kryptografisesti otsikon ja hyötykuorman käyttämällä joko HMAC-salaisuutta (HS256) tai epäsymmetristä avainparia (RS256/ES256). Dekooderi näyttää otsikon ja hyötykuorman sisällön, mutta EI vahvista allekirjoitusta – se vaatii salaisen tai julkisen avaimen, ja se tulee aina tehdä palvelinpuolella ennen kuin luotat mihinkään JWT:hen. JWT-rakenteen ymmärtäminen on välttämätöntä todentamisongelmien virheenkorjauksessa, asiakkaan ja palvelimen välisen tiedonsiirron ymmärtämisessä ja sen varmistamisessa, että tunnukset on muodostettu oikein. Yleisiä virheenkorjausskenaarioita: "Miksi tunnus on hylätty?" (yleensä vanhentunut tai väärä yleisö), "Mille käyttäjälle tämä tunnus on?" (tarkista alivaatimus), "Milloin tämä vanhenee?" (exp väite) ja "Mitä käyttöoikeuksia tällä käyttäjällä on?" (muokatut vaatimukset, kuten roolit, laajuudet tai käyttöoikeudet). Tämä laskin käsittelee yleisimmät analyysit: rakenteen validointi (3 osaa, kelvollinen base64url), JSON-jäsennys, vanhenemistila (voimassa, vanhenee pian <7 päivää, vanhentunut), ei vielä voimassa oleva käsittely (nbf tulevaisuudessa) ja ihmisten luettava näyttö kaikista vakiovaatimuksista sekä täysi otsikko ja hyötykuorma JSON. Allekirjoitus näytetään, mutta sitä ei ole vahvistettu – tuotannon varmentamisessa tulee aina käyttää JWT-kirjastoa (jsonwebtoken, jose, PyJWT jne.) oikealla vahvistusavaimella.

PrimeCalcPro provides professional-grade tools trusted by businesses and academics.

1. 1Vaihe 1 – Liitä JWT-tunnus: Kopioi koko tunnus (yleensä pitkä merkkijono, joka alkaa eyJ:llä, koska eyJ on base64url-koodaus '{':lle, joka aloittaa JSON-otsikon). Tunnusmerkit ovat yleensä 100–2000+ merkkiä pitkiä hyötykuorman koosta riippuen.
2. 2Vaihe 2 – Token-rakenteen vahvistaminen: Laskin jakaa tunnuksen jaksoiksi. Kelvollisessa JWT:ssä on täsmälleen 3 osaa: otsikko, hyötykuorma, allekirjoitus. Jos splitit eivät tuota 3 osaa, merkki on väärin muotoiltu. Yleisiä syitä: katkaisu kopioinnin ja liittämisen aikana, puuttuvat osat API-vastauksissa tai muut kuin JWT-tunnukset (jotkut sovellusliittymät käyttävät läpinäkymättömiä tunnuksia, jotka eivät ole JWT:itä).
3. 3Vaihe 3 – Base64url-dekoodaus: Jokainen osa on base64url-dekoodattu. Base64url on URL-osoitteelle turvallinen muunnos base64:stä, joka käyttää - ja _ merkkien + ja / sijasta ja jättää täytteen (= pois). Nykyaikaisten selainten atob()-funktio käsittelee base64:ää, mutta vaatii muunnoksen: - → +, _ → /, lisää täyte. Jos dekoodaus epäonnistuu, tunnus on vioittunut.
4. 4Vaihe 4 – JSON-jäsennys: Dekoodatun otsikon ja hyötykuorman tulee olla kelvollisia JSON-objekteja. Jos JSON.parse epäonnistuu, tunnuksen sisältö on vioittunut tai tämä ei ole tavallinen JWT. Jotkut vanhat järjestelmät käyttävät "JWT:n kaltaisia" muotoja binaarisen tai muun kuin JSON-sisällön kanssa, jota ei pureta täällä.
5. 5Vaihe 5 – Vaatimusten purkaminen ja analysointi: Laskin poimii vakiovaatimukset (exp, iat, nbf, sub, iss, aud) ja näyttää ne ihmisen luettavassa muodossa. exp ja iat muunnetaan Unix-aikaleimoista päivämääriksi. Mukautetut vaatimukset näkyvät täyden hyötykuorman JSON-tiedostossa tarkastettavaksi.
6. 6Vaihe 6 — Vanhenemistilan laskenta: Nykyinen aika (nyt) verrattu voimassaoloajan vaatimukseen. Tilaluokat: VOIMASSA (voimassa > nyt + 7 päivää), PÄÄTTYY PIAN (voimassa > nyt, mutta < 7 päivää), PÄÄTTYNYT (voimassa < nyt, näkyy päivää sitten), EI KYLLÄ VOIMASSA (nbf > nyt, tunnus on myöhempää käyttöä varten). Jäljellä olevat päivät näytetään kontekstia varten.
7. 7Vaihe 7 – Allekirjoituksen näyttö (EI vahvistettu): Kolmas segmentti (allekirjoitus) näytetään, mutta sitä ei ole koskaan vahvistettu tällä työkalulla. Vahvistus vaatii salaisuuden (HMAC-algoritmeille) tai julkisen avaimen (epäsymmetrisille algoritmeille), ja se tulee tehdä palvelinpuolella käyttämällä oikeaa JWT-kirjastoa. Älä koskaan luota tuotantokoodin vahvistamattomaan JWT-sisältöön.

• !Hämmentävä dekoodaus ja tarkistaminen - tämä työkalu vain purkaa; allekirjoituksen vahvistus vaatii salausavaimen, ja se tulee tehdä palvelinpuolella JWT-kirjaston avulla.
• !Luota vahvistamattomaan JWT-sisältöön turvallisuuspäätöksissä – kuka tahansa voi väärentää pätevän näköisen tunnuksen; koskaan valtuuta ilman vahvistusta.
• !JWT:iden tallentaminen paikalliseen tallennustilaan arkaluontoisten tietojen kanssa – alttiina XSS-hyökkäyksille; käytä httpOnly suojattuja evästeitä tuotantoselainsovelluksissa.
• !Unohda käsitellä kellon vinoutta – salli 30–60 sekunnin toleranssi exp/nbf-vertailuissa hajautettujen palvelimien välillä.
• !Pitkäikäisten JWT:iden käyttäminen ilman kiertoa – kerran myönnettyjä JWT:itä ei voida helposti peruuttaa; käytä lyhytaikaista pääsyä + päivitä tunnuksen kiertokuviota.