Opret en signeret JSON Web Token (JWT)

Hvad er JWT Builder?

JWT Builder er et onlineværktøj, der producerer et signeret JSON Web Token (JWT) fra en JSON-nyttelast og en HMAC-hemmelighed. Det er rettet mod udviklere, der har brug for for hurtigt at generere et testtoken for at kontrollere adfærden af en API, simuler en session autentificeret i Postman, eller genskabe en fejl relateret til udløbet eller omfanget af et token.

I modsætning til vores JWT-dekoder, som bare læser et token eksisterende, JWT Builder laver et komplet token: det bygger headeren, koder nyttelast, beregner HMAC-signaturen og samler alt i et kompakt format header.payload.signature forventes af alle JWT-biblioteker på markedet.

Hvorfor generere en JWT?

Det er ikke meningen, at en JWT-bygger skal udstede produktionstokens. Det er frem for alt et værktøj til udvikling og test. Her er de mest almindelige scenarier:

• Integrationstests: Fremstil forudsigelige JWT'er til at køre E2E-tests der rammer beskyttede endepunkter uden at stole på den rigtige identitetsudbyder.
• API-håner: Erstat midlertidigt et opkald til IdP med en signeret JWT lokalt med den samme testhemmelighed.
• Lokal udvikling: Opret forbindelse til din egen backend ved manuelt at generere en token, der indeholder de ønskede krav, uden at skulle gennemgå hele OAuth2-flowet.
• Demoer: illustrerer en godkendelsesrejse eller arbejdsgang baseret på tilladelser uden at have en rigtig IdP ved hånden.
• Bug-reproduktion: smid et udløbet token, et token med en Forkert aud, et token uden visse krav, at teste fejlstierne for din API.
• Fejlretning af en brugerdefineret parser: injicer JWT'er specielt konstrueret til test en hjemmelavet parser.

Sammensætning af en JWT

En signeret JWT er sammensat af tre segmenter adskilt af en prik, hver indkodet Base64URL (variant af Base64 uden polstring og med -/_ ved i stedet for +//):

• Header: et JSON-objekt, der beskriver signaturalgoritmen og typen af token, for eksempel {"alg":"HS256","typ":"JWT"}. JWT Builder genererer det automatisk fra af den algoritme, du vælger.
• Payload: et vilkårligt JSON-objekt, der indeholder kravene af tokenet (subject, tilladelser, udløbsdatoer). Dette er den del, du leverer.
• Signatur: en HMAC-SHA beregnet ved sammenkædning base64url(header) + "." + base64url(nyttelast) med din hemmelige nøgle. Det er hende, der garanterer tokens integritet.

Brug cases i detaljer

• API-mock til E2E-testning: din Cypress- eller Playwright-suite skal kalde en API som kræver en Autorisation: Bearer .... I stedet for at orkestrere et komplet login på hver test underskriver vi en JWT i farten med den delte hemmelighed og injicerer den i headeren.
• SSO-demo: præsentere en fødereret godkendelsesrejse uden afhængighed af en online-IDP.
• Testopstilling: generer en deterministisk JWT fra en nyttelast, der er kendt for tjene som en stabil fastgørelse i enhedstests.
• Diagnose af en tilpasset parser: test af en hjemmelavet JWT-parser med tokens bevidst minimal eller bevidst bizar (manglende påstande, uventede typer).
• Læring: forstå konkret, hvordan en JWT er bygget ind ændring af nyttelasten og se signaturen ændre sig.

Understøttede algoritmer: HS256, HS384, HS512

Vores værktøj understøtter de tre standard HMAC-algoritmer i JWT-specifikationen (RFC 7519):

• HS256: HMAC med SHA-256. 32 byte signatur. Mest brugt i praksis, godt kompromis mellem hastighed og kryptografisk soliditet. Anbefalet som standard.
• HS384: HMAC med SHA-384. 48-byte signatur. Tilpasset sammenhænge, der kræver en højere sikkerhedsmargen.
• HS512: HMAC med SHA-512. 64 byte signatur. Den mest robuste, til prisen af en lidt større token.

HMAC eller RSA?

HS*-algoritmerne er symmetriske: den samme nøgle bruges til at signere og verificere. Det er hurtigt og nemt, men det betyder, at enhver tjeneste, der kan verificere et token, også er det i stand til at udsende dem. Hvis du har brug for at adskille disse to roller (en enkelt udsteder, flere forbrugere), vend til RS256/RS384/RS512-algoritmerne (RSA, asymmetrisk), som du kan verificere med vores JWT-verifikator.

Sikkerhed: Beskyttelse af din hemmelighed

Sikkerheden for en JWT, der er underskrevet i HMAC, afhænger helt og holdent på hemmelighedens fortrolighed. Nogle grundlæggende regler:

• Brug en lang, tilfældig hemmelighed. RFC 7518 anbefaler mindst størrelsen af algoritmeoutputtet (32 bytes for HS256, 48 for HS384, 64 for HS512). En adgangskode menneske som azerty123 er trivielt brute force, der kan angribes offline.
• Underskriv aldrig et JWT på klientsiden. Hemmeligheden ville blive fundet i koden JavaScript distribueres til browseren, udsat for enhver bruger. Underskriften skal altid forblive serversiden.
• Gem hemmeligheden i en miljøvariabel (f.eks. JWT_SECRET), aldrig i et Git-lager. Overvej at bruge en boks som HashiCorp Vault, AWS Secrets Manager eller Symfony Secrets afhængigt af din stak.
• Vend hemmeligheden regelmæssigt (nøglerotation), især efter enhver hændelse eller afgang af en person, der havde adgang til konfigurationen.
• JWT Builder er til test og læring. Til produktion, brug dit frameworks JWT-bibliotek (lcobucci/jwt, firebase/php-jwt, jose-php).

God reklamationspraksis

Nyttelasten er et gratis JSON-objekt, men RFC 7519 definerer et sæt registrerede krav at JWT-bibliotekerne ved, hvordan de skal tolke. Inkludering af de rigtige krav gør dit token bærbart og undgår subtile fejl:

• iss (udsteder): id for udstederen, for eksempel "https://api.example.com".
• sub (emne): identifikator for den pågældende person eller enhed, ofte ID bruger.
• aud (publikum): hvem tokenet er beregnet til, for at forhindre genbrug af en token på en anden API.
• exp (udløbstid): Unix-tidsstempel, hvorefter tokenet ikke længere er gyldigt. Inkluder altid, selv for et testtoken: et token uden udløb er en dårlig vane svær at rette op bagefter.
• nbf (ikke før): tidsstempel, før hvilket tokenet endnu ikke er gyldigt. Nyttigt til forhåndsudstedelse af et token, der kan aktiveres senere.
• iat (udstedt på): udstedelsestidsstempel, nyttigt til logning og tilbagekaldelse.
• jti (JWT ID): unik identifikator for tokenet, afgørende for idempotens og implementere en tilbagekaldelsesliste.

Typisk eksempel på nyttelast

{
  "iss": "https://api.example.com",
  "sub": "bruger-12345",
  "aud": "mobil-app",
  "iat": 1714723200,
  "exp": 1714726800,
  "jti": "9f2d6b1e-2c4a-4f8a-9c3a-87a2b8a4b7e1",
  "scope": "læs:profil skriv:profil"
}

Sådan bruger du værktøjet

1. Indtast nyttelasten som gyldig JSON. Det er et objekt, så det starter med { og slutter med }.
2. Angiv HMAC-hemmeligheden. Vælg en lang, tilfældig streng til produktionstokens.
3. Vælg algoritmen: HS256 som standard, HS384 eller HS512 alt efter dine behov.
4. Klik på opret. Den signerede JWT vises, klar til at indsætte i en header Autorisation: Ihændehaver ....
5. Du kan derefter bekræfte tokenet med den samme hemmelighed til bekræft konsistensen af rundturen, eller afkode for at genlæse dens indhold.

Ofte stillede spørgsmål

Anmodningseksempel

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

Inputskema

Endpoints

• GET https://cdrn.fr/api/v1/tools - lister alle tilgængelige værktøjer
• GET https://cdrn.fr/api/v1/tools/jwt-builder - henter skemaet for dette værktøj
• POST https://cdrn.fr/api/v1/tools/jwt-builder/execute - udfører dette værktøj med et JSON-payload