Dekodér JWT

Dekóduje. Neověřuje a nikdy netvrdí opak. Dekódování rozbalí to, co token říká sám o sobě; dokázat, že je token pravý, znamená zkontrolovat jeho podpis proti tajnému nebo veřejnému klíči, který ho vytvořil. Tento nástroj o klíč nežádá a nikdy žádný nedostane, takže se podpis hlásí jako neověřený, místo aby byl potichu předveden jako v pořádku.

Tři segmenty

Nároky, popsané

Sedm zaregistrovaných nároků z RFC 7519 a rejstříku IANA - iss, sub, aud, exp, nbf, iat a jti - se vytáhne z payloadu a dostane své vlastní názvy: vydavatel, subjekt, publikum, čas vypršení, ne dříve než, vydáno a identifikátor tokenu. Všechno ostatní, co do tokenu vložil váš systém, zůstává vidět v dekódovaném payloadu, místo aby se skrylo jen proto, že to není standardní.

Čas slovy, ne čísly

exp, iat a nbf jsou hodnoty NumericDate, tedy sekundy od 1. ledna 1970 UTC. Přečteny syrově neřeknou nic, proto se porovnávají s aktuálním časem a hlásí jako kolik zbývá, jak dávno byl token vydán nebo kdy začne platit. To bývá celá otázka ve chvíli, kdy token přestal fungovat.

alg: none se pojmenuje, nepřejde se

Nezabezpečený token nenese vůbec žádný kryptografický podpis. RFC 7519 jej pro určité vnitřní případy povoluje a neposkytuje žádnou ochranu proti pozměnění, proto se označuje výslovně, místo aby působil jako token, kterému prostě vyšel krátký třetí segment. Chybějící podpis nesmí být nikdy zaměněn za splněný.

Poškozený token dostane důvod

Špatný počet segmentů, rozbitý Base64URL a neplatný JSON uvnitř segmentu dávají každý vlastní zprávu. Selhání řekne, o který ze tří případů šlo, místo aby vrátilo prázdný výsledek a nechalo vás hádat, zda je token uříznutý, poškozený, nebo prostě není JWT.

Za touto stránkou není žádný koncový bod API. Token se dekóduje v paměti prohlížeče a nikdy se neodesílá, nezapisuje do logu ani neukládá, což tu váží víc než u většiny nástrojů: produkční přístupový token vložený na cizí web je přihlašovací údaj, který jste právě vyzradili.