logo
GeekFormat

Narzędzie JWT

Encoded Token172 charsZaktualizowano 2026-07
header
payload
signature
Valid JWTHS256
Secret38 chars
Header
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}
Claims details4 items
sub· Podmiot1234567890
name· NameJohn Doe
admin· Admintrue
iat· Wydano o151623902218.01.2018, 09:30:22
Header details2 items
algHS256HMAC (symetryczny)
typ· TypeJWT
All operations run locally in your browser; the Token and key are never sent to any server.

Darmowe narzędzie online do obsługi JWT, obsługuje dekodowanie, weryfikację i generowanie JWT Token, podgląd Header, Payload i informacji o podpisie, idealne do debugowania uwierzytelniania interfejsów.

Powiązane Rekomendacje

Przypadki użycia

  • Dekodowanie JWT online: szybkie rozdzielanie tokena podczas debugowania logowania OAuth 2.0 / OIDC, aby inspekcjonować algorytm Header i Claims Payload
  • Weryfikacja podpisów JWT: użyj Secretu / klucza publicznego, aby zweryfikować podpisy tokenów w czasie rzeczywistym i określić, czy 401 to 'zły podpis', 'wygasły' czy 'niedopasowany algorytm'
  • Generowanie testowych JWT podczas integracji: wydaj JWT w przeglądarce z testową parą kluczy, bez potrzeby tymczasowej zmiany kodu backendu, aby wygenerować token
  • Konwersja PEM ↔ JWK: OIDC IdP dał ci JWK, ale serwer potrzebuje PEM (lub odwrotnie) — konwertuj na miejscu zamiast pisać skrypt OpenSSL
  • Diagnozowanie 401 Unauthorized: krok po kroku sprawdzaj wygaśnięcie, dopasowanie alg do bramy, dopasowanie klucza i formatowanie PEM
  • Porównywanie RS256 vs PS256: wielu dostawców OIDC domyślnie używa RS256, podczas gdy AWS SigV4 preferuje PS256 — przełączaj algorytmy z tą samą parą kluczy RSA i porównuj wyniki
  • Nauka wewnętrznych mechanizmów JWT: zmień alg, edytuj Payload, zamień klucz w przeglądarce i obserwuj, jak podpis się łamie w czasie rzeczywistym — znacznie szybciej niż czytanie RFC

Funkcje

  • Dekodowanie + Weryfikacja + Generowanie w jednym miejscu: wklej token, aby rozdzielić Header/Payload/Signature, przełącz algorytm i klucz, aby zweryfikować podpis, edytuj Claims i podpisz ponownie, aby wygenerować nowy token — obejmuje pełny łańcuch rozwiązywania problemów JWT
  • Wszystkie 13 algorytmów obsługiwane: HS256/HS384/HS512 (HMAC), RS256/RS384/RS512 (RSA-PKCS1-v1_5), ES256/ES384/ES512 (ECDSA), PS256/PS384/PS512 (RSA-PSS), EdDSA — obejmuje OAuth 2.0, OIDC, JWS, bramy API i korporacyjne SSO
  • Formaty PEM i JWK: klucze RSA, ECDSA i Ed25519 akceptują ciągi PEM (z nagłówkami -----BEGIN PUBLIC KEY-----) i JSON JWK (pola kid/kty/n/e) — bezpośrednio wstaw wyjście OIDC /.well-known/jwks.json
  • Wiele form wprowadzania sekretu HMAC: surowy ciąg UTF-8, bajty hex lub zakodowany Base64/Base64URL — przełączaj jednym kliknięciem, aby nigdy nie zdarzyło się 'wygląda tak samo, ale podpis nie przechodzi'
  • Automatyczne generowanie par kluczy: pary kluczy RSA-2048, RSA-4096, P-256, P-384 i Ed25519 generowane w przeglądarce, prezentowane w formatach PEM i JWK do natychmiastowego użycia testowego
  • Semantyczne podświetlanie Claims: exp / iat / nbf automatycznie konwertowane na czytelny czas z podświetlonym statusem wygasły / jeszcze-nieważny / wydany; alg / typ / kid w Header oznaczone indywidualnie
  • 100% po stronie klienta, zero przesyłania: każde parsowanie, weryfikacja i podpisywanie działa przez natywny Web Crypto API przeglądarki — tokeny, klucze i payload nigdy nie opuszczają przeglądarki, zgodnie z zasadą bezpieczeństwa 'nigdy nie wklejaj produkcyjnych tokenów do losowych narzędzi online'
  • Kopiowanie jednym kliknięciem: Header, Payload, Signature i nowo wygenerowany token są niezależnie kopiowalne do dokumentacji, ticketów i poleceń curl

Jak Używać

  1. Wklej lub wpisz token: umieść ciąg JWT w polu wejściowym; narzędzie automatycznie rozdziela Header, Payload i Signature i wyświetla każdy jako JSON
  2. Wybierz algorytm: przełączaj między HS256 / RS256 / ES256 / PS256 / EdDSA; narzędzie wywnioskuje z Header.alg i oznacza wszelkie niedopasowania
  3. Importuj klucz: wklej sekret HMAC, ciąg PEM lub JSON JWK; dla algorytmów asymetrycznych kliknij 'Generuj parę kluczy', aby natychmiast uzyskać klucz testowy
  4. Weryfikuj lub podpisz ponownie: w trybie Decode weryfikuj kluczem publicznym i zobacz '✅ podpis ważny / ❌ podpis nieważny'; w trybie Encode edytuj Claims i podpisz kluczem prywatnym, aby wygenerować nowy token

Często Zadawane Pytania

Jakie są trzy części JWT?

Ciąg JWT ma formę `Header.Payload.Signature`, każdy segment jest zakodowany Base64URL. Header deklaruje algorytm (taki jak HS256, RS256) i typ tokena (typ: JWT); Payload niesie Claims użytkownika (oświadczenia), wspólne pola to sub (ID użytkownika), iat (czas wydania), exp (czas wygaśnięcia), nbf (not-before), aud (odbiorca), iss (wydawca); Signature jest wynikiem podpisania pierwszych dwóch segmentów kluczem, celem jest 'wykrywanie naruszeń', nie 'anty-wyciek'.

Czy mogę edytować Payload po dekodowaniu?

Możesz przeglądać i edytować, ale **nie fałszować**. Gdy tylko zmienisz Header lub Payload, oryginalny Signature staje się nieważny, a serwer odrzuci weryfikację. Aby zmodyfikowany token był ponownie ważny, musisz go **ponownie podpisać** tym samym algorytmem i tym samym kluczem — to właśnie dlatego to narzędzie oferuje 'dekodowanie + edycję + generowanie' w jednym: dekoduj, aby przeglądać, zmień i natychmiast wygeneruj nowy token do testowania, abyś nie musiał za każdym razem prosić backendu o tymczasową zmianę kodu do wydania.

Jaka jest różnica między HS256, RS256, ES256, PS256 i EdDSA?

HS256 używa HMAC z wspólnym sekretem (symetryczny), szybki, ale zarządzanie sekretem jest kluczowe. RS256 używa kluczy prywatnych/publicznych RSA (asymetryczny), wydawca podpisuje kluczem prywatnym, weryfikator używa publicznego. ES256 używa ECDSA z krzywymi eliptycznymi (P-256), krótszy podpis. PS256 używa RSA-PSS, bezpieczniejszy niż RS256. EdDSA (zwykle Ed25519) jest szybki i deterministyczny, zalecany dla OAuth 2.1.

Dlaczego mój JWT ciągle pokazuje 'Invalid Signature'?

Zwykle dzieje się tak, ponieważ klucz, format sekretu, algorytm lub kodowanie Base64URL nie pasują dokładnie. Dodatkowa spacja, niewłaściwa nowa linia PEM lub pomieszanie Base64 z Base64URL wystarczy. Sprawdź zgodność bajt po bajcie i potwierdź, że Header.alg pasuje do wybranego algorytmu.

Czy ten sam klucz RSA może krzyżowo weryfikować RS256 i PS256?

Nie. RS256 używa RSASSA-PKCS1-v1_5, PS256 używa RSA-PSS. Nawet z tym samym kluczem RSA nie mogą się krzyżowo weryfikować. Sygnatariusz i weryfikator muszą używać tego samego algorytmu.

Czym jest atak alg:none?

Atakujący zmienia Header do `{"alg":"none"}` (brak podpisu) lub zamienia RS256 na HS256 (używając klucza publicznego, jakby był sekretem HMAC). Serwer musi wymusić białą listę algorytmów i nigdy nie pozwalać tokenowi decydować, którego algorytmu używać.

Jak konwertuję między PEM i JWK?

PEM to klasyczna notacja OpenSSL z liniami BEGIN/END. JWK to JSON i jest powszechny w OAuth/OIDC. Dostawcy OIDC często publikują klucze publiczne przez `/.well-known/jwks.json`. To narzędzie może bezpośrednio przetwarzać formaty PEM i JWK.

Czy przeglądarka może bezpośrednio weryfikować podpisy JWT?

Tak. Natywny Web Crypto API przeglądarki (`window.crypto.subtle`) obsługuje podpisywanie i weryfikację HMAC, RSA, ECDSA, RSA-PSS i Ed25519, bez bibliotek innych firm. To narzędzie używa `crypto.subtle.importKey` i `crypto.subtle.verify` na froncie do każdej weryfikacji, dlatego nigdy nie przesyła twoich tokenów ani kluczy. Uwaga: Web Crypto jest dostępne tylko w bezpiecznych kontekstach: **HTTPS** lub `localhost`.

Czy mój token jest wysyłany do serwera?

Nie. Całe parsowanie, weryfikacja i podpisywanie w tym narzędziu działa w przeglądarce przez natywny Web Crypto API. Token, Header, Payload, Signature, sekret / klucz prywatny i wszelkie wygenerowane pary kluczy nigdy nie są wysyłane do serwera. Otwórz kartę Network DevTools przeglądarki, a nie zobaczysz żadnego żądania wychodzącego niosącego zawartość tokena. Strona może być używana offline po załadowaniu.

Czy JWT jest bezpiecznym miejscem na wrażliwe informacje o użytkowniku?

**Nie.** Payload JWT jest domyślnie jawnym tekstem — każdy z tokenem może go zdekodować Base64URL i odczytać zawartość. Nie ma szyfrowania. **Nigdy nie umieszczaj** haseł, krajowych numerów ID, numerów kart kredytowych, kluczy API, tokenów dostępu ani tokenów odświeżania w jawnym tekście w JWT. Jeśli potrzebujesz szyfrowania, użyj JWE (RFC 7516) zamiast JWS. JWT są odpowiednie dla niewrażliwych Claims (ID użytkownika, rola, czas wygaśnięcia, ID najemcy); wrażliwe dane powinny być wyszukiwane po stronie serwera za pomocą `sub`.

Czym jest Dekodowanie, Weryfikacja i Generowanie JWT?

JWT (JSON Web Token) to otwarty standard zdefiniowany przez IETF w RFC 7519 (RFC 7515 opisuje formę podpisywania JWS, RFC 7516 opisuje szyfrowanie JWE, RFC 7517 definiuje klucze JWK) do bezpiecznego przesyłania 'oświadczonych' informacji o użytkowniku między żądaniami HTTP, przepływami OIDC i wywołaniami mikrousług. Standardowy ciąg JWT składa się z trzech segmentów zakodowanych Base64URL: Header (algorytm i typ), Payload (Claims, dane użytkownika) i Signature (podpis oparty na kluczu nad pierwszymi dwoma). Trzy segmenty są połączone kropką `.`, np. `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.

**JWT nie jest szyfrowaniem.** To najczęstsze nieporozumienie. Payload jest domyślnie jawnym tekstem — każdy może go zdekodować Base64URL i odczytać zawartość. JWT zapewnia **wykrywanie naruszeń**, nie poufność: serwer ponownie podpisuje Header.Payload wspólnym kluczem i porównuje z Signature tokena. Jeśli się zgadzają, token nie został zmieniony podczas transportu. To metafora 'biletu kolejowego z antyfałszywowym stemplem': inspektor pyta, czy bilet jest prawdziwy, nie czy kod QR jest nieczytelny.

JWT ładnie dzieli odpowiedzialności między 13 algorytmów. **Rodzina HMAC** (HS256/HS384/HS512) używa symetrycznego klucza do podpisywania i weryfikacji, szybka i prosta, odpowiednia dla pojedynczej usługi lub zaufanego klastra; sekret musi mieć co najmniej długość skrótu (np. ≥ 32 bajty dla HS256). **Rodzina RSA** (RS256/RS384/RS512) używa RSASSA-PKCS1-v1_5, najczęstszego schematu asymetrycznego — sygnatariusze mają klucz prywatny, weryfikatorzy mają klucz publiczny. **Rodzina RSA-PSS** (PS256/PS384/PS512) używa nowszego wypełnienia RSA-PSS z silniejszymi gwarancjami bezpieczeństwa, preferowana przez AWS SigV4 i nowoczesnych dostawców tożsamości OIDC. **Rodzina ECDSA** (ES256/ES384/ES512) używa krzywych eliptycznych (odpowiednio P-256/P-384/P-521) z krótszymi podpisami i lepszą wydajnością. **EdDSA** (głównie Ed25519) jest niezwykle szybka i deterministyczna (ten sam komunikat + ten sam klucz = ten sam podpis za każdym razem) i jest zalecanym algorytmem w OAuth 2.1 i nowych protokołach.

Bezpieczeństwo to miejsce, gdzie JWT potyka się w produkcji. OWASP JWT Cheat Sheet wymienia co najmniej cztery twarde zasady: (1) nigdy nie umieszczaj haseł, krajowych dowodów osobistych, numerów kart lub kluczy API jako jawnego tekstu w Payload; (2) serwer musi **nigdy nie ufać polu alg** zadeklarowanemu w Header Tokena — musi weryfikować z zakodowanym na sztywno algorytmem, w przeciwnym razie atakujący przepisujący nagłówek do `alg: none` omija wszystko (to jest źródło historycznych CVE, takich jak CVE-2015-9235); (3) sekrety HMAC muszą być losowe i mieć co najmniej 32 bajty, nigdy krótkie ciągi; (4) weryfikacja to więcej niż tylko sprawdzanie podpisów — musisz także walidować `exp` (wygaśnięcie), `nbf` (not-before), `iss` (wydawca) i `aud` (odbiorca). To narzędzie podświetla każdy z tych Claims w UI, abyś mógł natychmiast zobaczyć, czy awaria to problem podpisu, problem czasu czy problem Claims.

JWT nie jest zamiennikiem sesji. Sesje przechowują stan użytkownika na serwerze (Redis lub baza danych); JWT pakuje stan do tokena. Architektury mikrousług, bezstanowe API, klienci mobilni i konfiguracje z dużą liczbą CORS korzystają z JWT; tradycyjne systemy korporacyjne i przepływy wymagające natychmiastowego odwołania (np. 'wyrzuć tego użytkownika teraz') są nadal lepiej obsługiwane przez sesje. To narzędzie obejmuje zarówno czyste debugowanie JWT, jak i kroki parsowania Tokena / weryfikacji podpisu / edycji Payload migracji z sesji do JWT.

Code Examples

50 lines of Node.js: hand-written HS256 sign and verify

javascript

Distills JWT's core mechanism: encode Header and Payload in Base64URL, then HMAC-SHA256 the `header.payload` string. In production, use a library like jsonwebtoken or jose — this snippet exists to make signature failures debuggable.

const crypto = require('node:crypto')

function b64url(input) {
  return Buffer.from(input)
    .toString('base64')
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '')
}

function hmacSign(data, secret) {
  return b64url(crypto.createHmac('sha256', secret).update(data).digest())
}

function sign(payload, secret) {
  const header = b64url(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
  const body = b64url(JSON.stringify(payload))
  const signature = hmacSign(`${header}.${body}`, secret)
  return `${header}.${body}.${signature}`
}

function verify(token, secret) {
  const [h, p, s] = token.split('.')
  const expected = hmacSign(`${h}.${p}`, secret)
  const a = Buffer.from(s)
  const b = Buffer.from(expected)
  return a.length === b.length && crypto.timingSafeEqual(a, b)
}

const SECRET = 'my-super-secret-key'
const payload = { userId: 42, role: 'admin', exp: Math.floor(Date.now() / 1000) + 3600 }
const token = sign(payload, SECRET)

console.log(token)
console.log(verify(token, SECRET))       // true
console.log(verify(token, 'wrong-key'))  // false

Browser-side: Web Crypto API for HMAC signing

html

The core idea of this tool's front-end: use the browser's native crypto.subtle for HMAC, RSA, ECDSA, RSA-PSS and Ed25519 verification — no third-party library needed. Drop this into any HTML page to mint HS256 tokens.

<!doctype html>
<html>
  <body>
    <pre id="out"></pre>
    <script>
      const out = document.getElementById('out')

      const b64url = buf =>
        btoa(String.fromCharCode(...new Uint8Array(buf)))
          .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

      const b64urlStr = str => b64url(new TextEncoder().encode(str))

      async function sign(payload, secret) {
        const header = b64urlStr(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
        const body = b64urlStr(JSON.stringify(payload))
        const data = new TextEncoder().encode(`${header}.${body}`)

        const key = await crypto.subtle.importKey(
          'raw',
          new TextEncoder().encode(secret),
          { name: 'HMAC', hash: 'SHA-256' },
          false,
          ['sign']
        )

        const sig = await crypto.subtle.sign('HMAC', key, data)
        return `${header}.${body}.${b64url(sig)}`
      }

      ;(async () => {
        const token = await sign({ user: 'alice', role: 'admin' }, 'browser-demo-secret')
        out.textContent = token
      })()
    </script>
  </body>
</html>

Node.js: verify RS256 with jose (the right way)

javascript

Use a mature library like jose, jsonwebtoken, or PyJWT in production — never roll your own. This snippet shows how jose verifies an RS256 token, prints the failure reason on error (alg mismatch, bad signature, expired, kid not found, etc).

import { jwtVerify, importSPKI } from 'jose'
import { readFile } from 'node:fs/promises'

const token = 'eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.payload.signature'
const publicKeyPem = await readFile('public.pem', 'utf8')

try {
  const { payload, protectedHeader } = await jwtVerify(
    token,
    await importSPKI(publicKeyPem, 'RS256'),
    {
      issuer: 'https://idp.example.com',
      audience: 'my-app',
      algorithms: ['RS256'],     // critical: algorithm whitelist blocks alg:none and HS256-substitution attacks
    }
  )
  console.log('alg =', protectedHeader.alg)
  console.log('sub  =', payload.sub)
} catch (err) {
  console.error('verify failed:', err.code, err.message)
  // common: ERR_JWT_EXPIRED / ERR_JWS_INVALID / ERR_JWS_SIGNATURE_VERIFICATION_FAILED
}

Python: parse a token and print its Claims with PyJWT

python

The most common way to debug JWT on the Python side. PyJWT's decode() validates exp / nbf / iat by default and returns the result as a plain dict.

import jwt

token = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw'

# Parse (no signature check, just look at Header and Payload)
print(jwt.get_unverified_header(token))
# {'alg': 'HS256', 'typ': 'JWT'}

print(jwt.decode(token, options={'verify_signature': False}))
# {'sub': '1234'}

# Full verification
claims = jwt.decode(
    token,
    'my-super-secret-key',
    algorithms=['HS256'],
    audience='my-app',
    issuer='my-service',
)
print(claims['sub'])

Supported Video Formats

FormatMIMEBrowser supportWhen to use
HS256 / HS384 / HS512HMAC + SHA-256/384/512UniversalAlgorytm z kluczem symetrycznym: ten sam Secret służy do podpisywania i weryfikacji. Jest prosty i szybki, dobry dla klastra usług działającego w zaufanej strefie. Secret powinien mieć co najmniej 32 bajty dla HS256, 48 dla HS384 i 64 dla HS512.
RS256 / RS384 / RS512RSASSA-PKCS1-v1_5 + SHA-2Web Crypto APINajpopularniejszy algorytm asymetryczny. Podpis tworzysz kluczem prywatnym, a weryfikujesz kluczem publicznym. To domyślny wybór w wielu providerach OIDC, bramkach API i firmowym SSO.
PS256 / PS384 / PS512RSA-PSS + SHA-2Web Crypto APIRSA-PSS to nowszy i bezpieczniejszy następca RS256. AWS SigV4, AWS Cognito i współczesne providery OIDC coraz częściej go preferują. saltLength trzeba ustawić jawnie, żeby weryfikacja była zgodna.
ES256 / ES384 / ES512ECDSA + P-256/P-384/P-521Web Crypto APIPodpisy oparte na krzywych eliptycznych. Są krótkie (ES256 ma tylko 64 bajty), szybkie i zmniejszają rozmiar JWT. Sign in with Apple domyślnie używa ES256.
EdDSA (Ed25519)Ed25519 / Ed448Web Crypto APINowoczesny, wydajny algorytm podpisu. Podpisy są deterministyczne (ten sam komunikat + ten sam klucz = ten sam podpis), bez ryzyka ponownego użycia nonce, więc dobrze pasuje do nowych protokołów.

Output Example

A real MP3 file encoded to a Data URI — copy-ready:

Header (Base64URL): eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload (Base64URL): eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzE2MjM5MDIyfQ
Signature: kZJfaYjK3iCkVFL5EL9zGRZ5SmD8_x2h6B5c7pVFfVGo

Privacy & Security

Ten warsztat JWT działa w 100% w Twojej przeglądarce, wspierany przez natywny Web Crypto API przeglądarki. Token, który wklejasz, Header, Payload, Signature, sekret HMAC, wszelkie klucze prywatne RSA/ECDSA, wszelkie wygenerowane pary kluczy i każde obliczenie podpisu/weryfikacji pozostają na Twoim urządzeniu — nigdy nie podróżują do serwera, nigdy nie są logowane, nigdy analizowane i nigdy buforowane. Strona może być używana offline po załadowaniu. Najlepsza praktyka: nigdy nie wklejaj długotrwałych tokenów produkcyjnych ani produkcyjnych kluczy prywatnych do żadnego narzędzia online, w tym tego. To narzędzie jest odpowiednie do debugowania, testowania integracji, nauki i generowania tokenów testowych — produkcyjne sekrety i klucze prywatne powinny być obsługiwane w kontrolowanym, lokalnym środowisku.

Authoritative References

Troubleshooting

Invalid Signature: 'signature is invalid'

Token i klucz weryfikacji nie pasują do siebie. Zwykłe przyczyny: (1) klucz serwera i klucz, który wkleiłeś do narzędzia, są różne (najczęstsze); (2) klucz zawiera niewidoczne znaki (spacja na końcu, nowa linia, znak o zerowej szerokości); (3) Base64 i Base64URL są mieszane; (4) wybrano zły algorytm (Header mówi HS256, serwer weryfikuje jako RS256 lub odwrotnie). Najpierw sprawdź, czy klucz pasuje bajt po bajcie: zwróć uwagę na końcowe nowe linie PEM, końcowe spacje sekretu HMAC i wartości `k` JWK, które mogły zostać błędnie zdekodowane przez URL. Potwierdź, że algorytm w narzędziu pasuje do Header.alg tokena. Użyj decode-plus-verify tego narzędzia, aby odtworzyć dokładny błąd i potwierdzić, że zdarza się między 'dekodowanie udane' a 'weryfikacja nieudana'.

HTTP 401 Unauthorized: Token Expired lub iat w przyszłości

Weryfikacja podpisu przeszła, ale `exp` jest w przeszłości (Token Expired), `nbf` jest nadal w przyszłości (Not Before) lub `iat` jest później niż aktualny czas serwera (często z powodu przesunięcia zegara). Innym częstym przypadkiem jest niedopasowany `aud` (odbiorca): token został wydany dla Aplikacji A, ale zweryfikowany przez Aplikację B. Użyj podświetlonego obszaru Claims w tym narzędziu, aby natychmiast zobaczyć status exp / nbf / iat. Czerwony exp = wygasły, wydaj ponownie. Czerwony nbf = jeszcze nieważny, sprawdź, czy iat jest czasem przyszłym. Czerwony aud = zły odbiorca, sprawdź, czy serwer ma skonfigurowany prawidłowy odbiorca.

Błąd importu PEM lub JWK

PEM ma dodatkowe puste linie lub brakuje markerów nagłówka/stopki (`-----BEGIN PUBLIC KEY-----`); JWK brakuje wymaganych pól (`kty` / `n` / `e` / `kid`); wartość `k` JWK brakuje wypełnienia Base64URL (musi być wypełnione `=` lub ściśle pozbawione `=`); prywatny klucz RSA jest importowany jako klucz publiczny; prywatny klucz Ed25519 (32-bajtowe ziarno) jest dostarczany jako 64 bajty. Ponownie wyeksportuj standardowy PEM PKIX za pomocą `openssl rsa -in key.pem -pubout -outform PEM` lub `openssl ec -in key.pem -pubout`; dla JWK użyj surowego wyjścia z endpointu OIDC Discovery `/.well-known/jwks.json` zamiast ręcznego kodowania. To narzędzie automatycznie wykrywa nagłówki PEM, brakujące wypełnienie i brakujące pola JWK i podpowiada.

RS256 vs PS256 awarie podpisu między językami

RS256 używa RSASSA-PKCS1-v1_5, PS256 używa RSA-PSS. Te dwa **nie mogą się krzyżowo weryfikować** — token podpisany RS256 przez dany klucz RSA zawsze zawiedzie weryfikację PS256, a podpis może różnić się długością o kilka bajtów. Upewnij się, że sygnatariusz i weryfikator używają tego samego algorytmu. AWS SigV4 używa PS256, większość dostawców OIDC używa RS256. RSA-PSS ma również parametr `saltLength` — OpenSSL domyślnie 32, jose domyślnie 32, `rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}` Go jest właściwym odpowiednikiem. Ustal to przed testowaniem integracji między językami.

Atak alg: none i atak podmiany klucza HS256

Serwer wybiera algorytm weryfikacji na podstawie alg zadeklarowanego w Header tokena. Atakujący przepisuje nagłówek do `alg: none` (brak podpisu) lub przepisuje token RS256 na HS256 (używając klucza publicznego, jakby był wspólnym sekretem HMAC) i omija weryfikację. Historyczne CVE, takie jak CVE-2015-9235 (jsonwebtoken) i CVE-2022-23529 (wiele bibliotek Node), wywodzą się z tego wzorca. Serwer musi wymusić białą listę algorytmów — na przykład `algorithms: ['RS256']` — i nigdy nie pozwalać tokenowi decydować, którego algorytmu używać. UI tego narzędzia pokazuje zarówno Header.alg, jak i algorytm, który faktycznie wybrałeś, i oznacza niedopasowania: to jest sama demonstracja na żywo 'klient nie musi ufać Header.alg'.