Ustvariti podpisan JSON Web Token (JWT)

generira podpisan JWT (HS256, HS384, HS512) iz JSON payloada in HMAC skrivnosti, pripravljen za vaše API teste ali avtentikacijske tokene

Kaj je JWT Builder?

JWT Builder je spletno orodje, ki izdela podpisan spletni žeton JSON (JWT) iz obremenitve JSON in skrivnosti HMAC. Namenjen je razvijalcem, ki potrebujejo za hitro generiranje testnega žetona za preverjanje vedenja API-ja simulirajte sejo overjen v programu Postman ali reproducirati napako, povezano s potekom ali obsegom žetona.

Za razliko od našega dekoderja JWT, ki samo prebere žeton obstoječe, JWT Builder izdela celoten žeton: zgradi glavo, kodira koristno obremenitev, izračuna podpis HMAC in sestavi vse v kompaktni obliki header.payload.signature pričakujejo vse knjižnice JWT na trgu.

Zakaj ustvariti JWT?

Graditelj JWT ni namenjen izdajanju proizvodnih žetonov. Predvsem je orodje za razvoj in testiranje. Tukaj so najpogostejši scenariji:

  • Integracijski testi: ustvarite predvidljive JWT za poganjanje testov E2E ki dosežejo zaščitene končne točke, ne da bi se zanašali na pravega ponudnika identitete.
  • API Mocks: Začasno zamenjajte klic IdP s podpisanim JWT lokalno z isto testno skrivnostjo.
  • Lokalni razvoj: povežite se z lastnim zaledjem tako, da ročno ustvarite a žeton, ki vsebuje želene zahtevke, ne da bi morali iti skozi celoten tok OAuth2.
  • Predstavitve: ponazorite pot preverjanja pristnosti ali potek dela na podlagi dovoljenja, ne da bi imeli pri roki pravi IdP.
  • Razmnoževanje napak: ponaredite žeton, ki je potekel, žeton z Nepravilen aud, žeton brez določenih trditev, za testiranje poti napak vaš API.
  • Odpravljanje napak v razčlenjevalniku po meri: vnesite JWT-je, izdelane posebej za preizkusite domači razčlenjevalnik.

Sestava JWT

Podpisani JWT je sestavljen iz treh segmentov, ločenih s piko, od katerih je vsak kodiran v Base64URL (različica Base64 brez oblazinjenja in s -/_ na namesto +//):

  • Glava: predmet JSON, ki opisuje algoritem podpisa in vrsto žetona, na primer {"alg":"HS256","typ":"JWT"}. JWT Builder ga samodejno ustvari iz algoritma, ki ga izberete.
  • Koristni tovor: poljuben objekt JSON, ki vsebuje zahtevke žetona (predmet, dovoljenja, datumi poteka). To je del, ki ga zagotovite vi.
  • Podpis: HMAC-SHA, izračunan na podlagi veriženja base64url(glava) + "." + base64url(payload) z vašim skrivnim ključem. Ona je tista zagotavlja celovitost žetona.

Primeri uporabe v podrobnostih

  • Lažni API za testiranje E2E: vaša zbirka Cypress ali Playwright mora klicati API ki zahteva Authorization: Bearer .... Namesto orkestriranja popolne prijave na pri vsakem preizkusu sproti podpišemo JWT s skupno skrivnostjo in jo vstavimo v glavo.
  • SSO Demo: predstavi zvezno pot preverjanja pristnosti brez odvisnosti spletnega IdP.
  • Test Fixture: ustvarite deterministični JWT iz tovora, za katerega je znano služijo kot stabilna stalnica v testih enot.
  • Diagnoza razčlenjevalnika po meri: testiranje domačega razčlenjevalnika JWT z žetoni namerno minimalno ali namerno bizarno (manjkajoče trditve, nepričakovane vrste).
  • Učenje: natančno razumejte, kako je JWT vgrajen spreminjanje nosilnosti in opazovanje spremembe podpisa.

Podprti algoritmi: HS256, HS384, HS512

Naše orodje podpira tri standardne algoritme HMAC specifikacije JWT (RFC 7519):

  • HS256: HMAC s SHA-256. 32-bajtni podpis. V praksi se najbolj uporablja, dober kompromis med hitrostjo in kriptografsko trdnostjo. Privzeto priporočeno.
  • HS384: HMAC s SHA-384. 48-bajtni podpis. Prilagojeno kontekstom, ki zahtevajo višjo varnostno mejo.
  • HS512: HMAC s SHA-512. 64 bajtni podpis. Najbolj robusten, po ceni malo večjega žetona.

HMAC ali RSA?

Algoritmi HS* so simetrični: za podpisovanje in preverjanje se uporablja isti ključ. Je hitro in enostavno, vendar to pomeni, da je tudi katera koli storitev, ki lahko preveri žeton ki jih je sposoben oddajati. Če morate ločiti ti dve vlogi (en izdajatelj, več potrošniki), se obrnite na algoritme RS256/RS384/RS512 (RSA, asimetrični), kar lahko preverite z našim preverjevalnikom JWT.

Varnost: varovanje vaše skrivnosti

Varnost JWT, podpisanega v HMAC, je v celoti odvisna od zaupnosti skrivnosti. Nekaj osnovnih pravil:

  • Uporabite dolgo, naključno skrivnost. RFC 7518 priporoča vsaj velikost izhoda algoritma (32 bajtov za HS256, 48 za HS384, 64 za HS512). Geslo človek, kot je azerty123, je trivialno napadljiv brez povezave.
  • Nikoli ne podpišite JWT na strani odjemalca. Skrivnost bi našli v kodi JavaScript, distribuiran brskalniku, izpostavljen vsem uporabnikom. Podpis mora vedno ostati strani strežnika.
  • Skrivnost shranite v spremenljivko okolja (npr. JWT_SECRET), nikoli v repozitoriju Git. Razmislite o uporabi trezorja, kot je HashiCorp Vault, AWS Secrets Manager ali Symfony Secrets, odvisno od vašega sklada.
  • Redno obračajte skrivnost (rotacija ključev), zlasti po kakršnem koli incidentu ali odhod osebe, ki je imela dostop do konfiguracije.
  • JWT Builder je namenjen testiranju in učenju. Za proizvodnjo, uporabite knjižnico JWT svojega ogrodja (lcobucci/jwt, firebase/php-jwt, jose-php).

Dobre reklamacijske prakse

Tovor je brezplačen objekt JSON, vendar RFC 7519 definira nabor registriranih zahtevkov ki jih znajo knjižnice JWT interpretirati. Če vključite prave trditve, postane vaš žeton prenosljiv in izogiba se subtilnim napakam:

  • iss (izdajatelj): identifikator izdajatelja, na primer "https://api.example.com".
  • sub (subject): identifikator zadevne osebe ali subjekta, pogosto ID uporabnik.
  • aud (občinstvo): komu je žeton namenjen, da se prepreči ponovna uporaba žeton na drugem API-ju.
  • exp (čas poteka): časovni žig Unix, po katerem žeton ni več veljaven. Vedno vključi, tudi za testni žeton: žeton brez poteka je a slabo navado, ki jo je pozneje težko popraviti.
  • nbf (ne prej): časovni žig, pred katerim žeton še ni veljaven. Uporabno za predhodno izdajo žetona, ki ga je mogoče aktivirati pozneje.
  • iat (izdano na): časovni žig izdaje, uporaben za beleženje in preklic.
  • jti (JWT ID): enolični identifikator žetona, bistven za idempotenca in za izvajanje seznama preklica.

Tipičen primer tovora

{
  "iss": "https://api.example.com",
  "sub": "uporabnik-12345",
  "aud": "mobilna aplikacija",
  "iat": 1714723200,
  "exp": 1714726800,
  "jti": "9f2d6b1e-2c4a-4f8a-9c3a-87a2b8a4b7e1",
  "scope": "read:profile write:profile"
}

Kako uporabljati orodje

  1. Vnesite tovor kot veljaven JSON. Je predmet, torej se začne z { in se konča z }.
  2. Določite skrivnost HMAC. Izberite dolg, naključen niz za proizvodne žetone.
  3. Izberite algoritem: privzeto HS256, HS384 ali HS512 glede na vaše potrebe.
  4. Kliknite ustvari. Prikaže se podpisani JWT, pripravljen za lepljenje v glavo Pooblastilo: Nosilec ....
  5. Nato lahko preverite žeton z isto skrivnostjo za potrdite doslednost povratnega potovanja ali dekodirajte za ponovno branje njegovo vsebino.

Pogosta vprašanja

Kateri algoritem izbrati: HS256, HS384, HS512?

Za skoraj vse primere je HS256 prava izbira. Ponuja raven popolnoma zadostna varnost za avtentikacijske žetone s kompaktnim podpisom (32 bajtov) in hiter izračun. HS384 in HS512 sta utemeljena samo v kontekstu natančne regulativne zahteve ali če upravljate žetone z zelo dolgo življenjsko dobo. Velikost Zaradi višjega podpisa je vsaka zahteva HTTP težja.

Kako ustvarim par RSA za podpis svojih JWT?

Z OpenSSL v dveh ukazih: openssl genrsa -out private.pem 2048 za ključ private, nato openssl rsa -in private.pem -pubout -out public.pem za ekstrahiranje javni ključ. Za nove storitve zdaj priporočamo varnostne ključe. 3072 bitov ali 4096 bitov. Zasebni ključ ostane na strani pošiljatelja; javni ključ je prosto distribuira storitvam, ki morajo preveriti žetone.

Kakšen je priporočen čas poteka?

Za žeton za dostop: 5 do 15 minut. Za žeton za osvežitev: nekaj dni nekaj tednov, vendar z mehanizmom za preklic na strani strežnika. Več ko je žeton dolgoživa, večje je delovno okno v primeru puščanja. Za testne JWT, vi lahko traja velikodušneje, vendar se izogibajte exp več let: na koncu uhajajo v repozitorije Git.

Ali se lahko podpišem z zelo kratkim skrivnim ključem?

Tehnično da, vendar je močno odsvetovano. Skrivnost HMAC manj kot 16 bajtov je šibko odporen na napade s surovo silo brez povezave in ga najdemo v narava orodij, ki v nekaj sekundah zlomijo JWT HS256 z nizko tajnostjo. The RFC 7518 priporoča vsaj velikost izhoda algoritma: 32 bajtov za HS256, 48 za HS384, 64 za HS512. Ustvarite svoje skrivnosti z openssl rand -base64 64.

Zakaj je moj tovor zavrnjen?

Tovor mora biti veljaven objekt JSON. Pogoste napake: enojni narekovaji namesto podvojitve, dodatna vejica pred }, vrednost brez narekovajev za niz. Potrdi najprej svoj JSON z našim oblikovalnikom JSON.

Ali lahko ustvarjeni JWT dešifrira nekdo drug?

Podpisani JWT ni šifriran: vsebina je samo kodirana Base64URL. Vse svet ga lahko bere. Če tovor vsebuje občutljive podatke, uporabite format JWE (JSON Web Encryption), ki doda šifriranje. Naše orodje ustvari JWS (samo podpisan).

Primer zahteve

curl -X POST https://cdrn.fr/api/v1/tools/jwt-builder/execute \
  -H "Content-Type: application/json" \
  -d '{"payload":"...","secret":"...","algorithm":"HS256"}'

Vhodna shema

Polje Tip Obvezno Privzeto
payload text
secret text
algorithm choice (HS256, HS384, HS512) HS256

Končne točke

  • GET https://cdrn.fr/api/v1/tools - izpiše vsa razpoložljiva orodja
  • GET https://cdrn.fr/api/v1/tools/jwt-builder - pridobi shemo tega orodja
  • POST https://cdrn.fr/api/v1/tools/jwt-builder/execute - izvede to orodje s JSON payloadom