JWT Decoder

Dekódujte a prohlédněte JSON Web Token

Zkusit příklad

JWT token

Běží lokálně · Bezpečné pro vkládání tajných údajů
Vyzkoušejte také:JWT Encoder

Co je JWT (JSON Web Token)?

JSON Web Token (JWT) je kompaktní formát tokenu bezpečný pro URL, definovaný v RFC 7519. Kóduje sadu claims jako objekt JSON, který poté podepíše — a volitelně zašifruje — aby příjemce mohl ověřit, že data nebyla pozměněna. JWT jsou de facto standardem pro bezstavové ověřování v REST API, systémech jednotného přihlášení a autorizaci mikroslužeb.

Anatomie JWT: Header · Payload · Signature

Každý JWT se skládá ze tří segmentů kódovaných v base64url oddělených tečkami. Header a Payload jsou prostý JSON — čitelný pro kohokoliv — zatímco Signature je kryptografická hodnota, kterou lze ověřit pouze správným klíčem.

Zakódovaný token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE3MjAwMDAwLCJleHAiOjE3MTcyMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

HeaderPayloadSignature
Header
json
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
json
{
  "sub":  "user123",
  "name": "Alice",
  "role": "admin",
  "iat":  1717200000,
  "exp":  1717203600
}

Proč používat dekodér JWT?

Surové JWT vypadají jako náhodný text. Tento nástroj okamžitě zobrazí Header a Payload jako formátovaný JSON, takže můžete zkoumat claims, kontrolovat časy expirace a auditovat volbu algoritmů bez napsání jediného řádku kódu.

🔍
Okamžitá inspekce claims
Zobrazte každý claim v Payload — sub, iss, aud, exp, vlastní role, oprávnění — formátovaný a čitelný jediným kliknutím.
🔓
Nepotřebuje tajný klíč
Header a Payload jsou veřejné; pouze Signature vyžaduje tajemství. Tento nástroj dekóduje obojí bez vašeho podpisového klíče.
⏱️
Analýza expirace a časových razítek
Unixová časová razítka (exp, iat, nbf) jsou automaticky převedena na čitelná data, takže okamžitě vidíte, zda token vypršel.
🔒
Běží zcela v prohlížeči
Vše se zpracovává lokálně — žádná data tokenu nejsou odesílána na žádný server. Bezpečné k použití s produkčními tokeny při ladění.

Referenční přehled standardních JWT claims

RFC 7519 definuje sedm registrovaných názvů claims. Nejsou povinné, ale jejich použití je pro interoperabilitu silně doporučeno. Do Payload můžete přidat libovolné vlastní claims.

ClaimPopisTyp
issVydavatelIdentifikuje, kdo token vydal — např. URL vašeho autentizačního serveru nebo název aplikace.string
subPředmětIdentifikuje hlavní subjekt, o němž JWT pojednává — typicky ID uživatele nebo servisní účet.string
audPříjemceIdentifikuje zamýšlené příjemce. Přijímající strana musí ověřit, že se toto shoduje s jejím identifikátorem.string | string[]
expČas expiraceUnixové časové razítko, po kterém token nesmí být přijat. Vždy nastavte, abyste omezili škody způsobené ukradeným tokenem.number
nbfPlatí odUnixové časové razítko, před kterým token nesmí být přijat. Užitečné pro plánování tokenů s budoucím datem.number
iatVydáno vUnixové časové razítko, kdy byl token vydán. Používá se pro výpočet stáří tokenu.number
jtiJWT IDJedinečný identifikátor tokenu. Umožňuje odvolání uložením a kontrolou použitých hodnot JTI na straně serveru.string

Podpisové algoritmy JWT

Claim záhlaví alg deklaruje, který algoritmus token podepsal. Výběr ovlivňuje bezpečnost, výkon a schopnost třetích stran ověřovat tokeny bez privátního klíče.

AlgoritmusRodinaTyp klíčePoznámky
HS256HMACSymmetricNejběžnější. Sdílené tajemství — kdo má tajemství, může podepisovat i ověřovat.
HS384HMACSymmetricSilnější varianta HMAC; mírné výkonnostní náklady.
HS512HMACSymmetricNejsilnější varianta HMAC.
RS256RSAAsymmetricNejpoužívanější asymetrický algoritmus (Google, Auth0, Okta). Veřejný klíč ověřuje bez privátního klíče.
RS384RSAAsymmetricVarianta RS s vyšší bezpečností.
RS512RSAAsymmetricNejsilnější varianta RS.
ES256ECDSAAsymmetricEliptická křivka — kratší podpisy než RSA, oblíbená na mobilních zařízeních a IoT.
PS256RSA-PSSAsymmetricRSA-PSS: modernější a bezpečnější než RS256 založený na PKCS1v1.5.
noneBez podpisu — kriticky nebezpečné. Nikdy nepřijímejte tokeny s alg: none v produkci.

Bezpečnostní úvahy

Dekódování JWT je vždy bezpečné. Důvěřovat JWT bez řádného ověření podpisu bezpečné není. Mějte tato pravidla na paměti vždy, když ve své aplikaci spotřebováváte tokeny.

Vždy bezpečné
  • Dekódovat a zkoumat JWT v nástrojích pro vývojáře nebo v tomto nástroji
  • Používat exp, iat a nbf k pochopení doby platnosti tokenu
  • Zaznamenávat claims Payload pro ladění (vynechat citlivé osobní údaje)
  • Číst záhlaví alg, abyste pochopili, jak byl token podepsán
Nikdy nedělejte toto
  • Důvěřovat claims v Payload bez ověření podpisu na straně serveru
  • Přijímat tokeny s alg: none — to znamená, že není vůbec žádný podpis
  • Ukládat přístupové tokeny v localStorage v aplikacích s vysokou bezpečností (preferujte httpOnly cookies)
  • Nastavovat exp daleko v budoucnosti pro tokeny nesoucí citlivá oprávnění

Typické případy použití

Ladění autentizačních toků
Vložte token z karty sítě v prohlížeči a zkontrolujte claims, vložené role a ověřte expiraci bez zásahu do produkčního kódu.
Inspekce tokenů třetích stran
Rychle přečtěte tokeny od Google, Auth0, Okta nebo Azure AD, zjistěte, jaké claims váš poskytovatel zahrnuje, a porovnejte je s očekávaným schématem.
Vývoj a testování API
Při psaní nebo testování API endpointů dekódujte autorizační záhlaví a potvrďte, že vaše logika generování tokenů nastavuje správné hodnoty sub, aud a scope.
Autorizace mikroslužeb
V service mesh každá služba ověřuje JWT od upstream volajícího. Dekódujte tokeny, abyste sledovali, která služba token vydala a jaká oprávnění uplatňuje.
Podpora a reakce na incidenty
Když uživatel nahlásí chybu ověřování, dekódujte jeho token a zkontrolujte, zda nevypršel, zda příjemce není chybný nebo zda nechybí požadovaný claim.
Bezpečnostní audit
Auditujte použití JWT napříč službami kontrolou volby algoritmů, oken expirace a zda nejsou citlivá data náhodně uložena v nezašifrovaném Payload.

Dekódování JWT v kódu

Header a Payload jsou kódovány v base64url — stačí kódování obrátit. Base64url nahrazuje + za - a / za _, a vynechává výplň =. Pouze Signature potřebuje tajný klíč.

JavaScript (browser)
function decodeJWT(token) {
  const [, payload] = token.split('.')
  const json = atob(payload.replace(/-/g, '+').replace(/_/g, '/'))
  return JSON.parse(json)
}
Node.js
const [, payload] = token.split('.')
const decoded = JSON.parse(
  Buffer.from(payload, 'base64url').toString()
)
Python
import base64, json

def decode_jwt(token):
    payload = token.split('.')[1]
    padding = '=' * (-len(payload) % 4)
    return json.loads(base64.urlsafe_b64decode(payload + padding))
CLI (bash + jq)
TOKEN="eyJhbGc..."
echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .

Nejčastější otázky

Mohu dekódovat JWT bez tajného klíče?
Ano. Header a Payload JWT jsou pouze JSON kódovaný v base64url — nikoliv zašifrovaný. Kdokoli je může dekódovat a přečíst. Tajemství (nebo privátní klíč pro algoritmy RS/ES) je potřeba pouze k ověření podpisu, čímž se potvrzuje, že token nebyl pozměněn.
Znamená dekódování JWT, že byl podpis ověřen?
Ne. Dekódování pouze čte claims. Ověření je samostatný krok, který kontroluje kryptografický podpis pomocí správného klíče. Vždy ověřte podpis, než budete důvěřovat jakýmkoli claims ve své aplikaci.
Jaký je rozdíl mezi HS256 a RS256?
HS256 používá jediné symetrické tajemství sdílené mezi vydavatelem a ověřovatelem — kdo má tajemství, může tokeny vytvářet i ověřovat. RS256 používá asymetrický pár klíčů: privátní klíč podepisuje, veřejný klíč ověřuje. S RS256 můžete distribuovat veřejný klíč, aby externí služby mohly ověřovat tokeny bez schopnosti je padělat.
Proč dekódování base64 někdy selhává?
JWT používají kódování base64url, které používá - místo + a _ místo /, a vynechává znaky výplně =. Standardní dekodéry base64 vyžadují + a / a mohou vyžadovat výplň. Přidejte výplň (doplňte na násobek 4 pomocí =) a vyměňte znaky před ručním dekódováním.
Je bezpečné vložit produkční JWT do tohoto nástroje?
Ano — tento nástroj běží zcela ve vašem prohlížeči a neposílá žádná data na žádný server. Mějte však na paměti, kdo může vidět vaši obrazovku nebo historii prohlížeče. U vysoce citlivých tokenů je dekódujte lokálně v terminálu.
Co znamená alg: none a je to nebezpečné?
alg: none znamená, že token nemá žádný kryptografický podpis — kdokoli může vytvořit token s libovolnými claims a nastavit alg na none. Některé rané JWT knihovny tyto tokeny přijímaly, čímž vznikla kritická zranitelnost. Bezpečná JWT knihovna vždy odmítá tokeny s alg: none, pokud není explicitně nakonfigurováno jinak. Tuto kontrolu nikdy nevypínejte.