Bygg en signerad JSON Web Token (JWT)

Vad är JWT Builder?

JWT Builder är ett onlineverktyg som producerar en signerad JSON Web Token (JWT) från en JSON-payload och en HMAC-hemlighet. Det riktar sig till utvecklare som behöver snabbt generera en testtoken för att verifiera ett API:s beteende, simulera en autentiserad session i Postman eller reproducera en bugg relaterad till en tokens utgång eller scope.

Till skillnad från vår JWT-avkodare, som nöjer sig med att läsa en befintlig token, tillverkar JWT Builder en fullständig token: den bygger headern, kodar payloaden, beräknar HMAC-signaturen och sätter ihop alltsammans i det kompakta format header.payload.signature som alla JWT-bibliotek på marknaden förväntar sig.

Varför generera en JWT?

En JWT-byggare är inte avsedd att utfärda produktionstokens. Det är framför allt ett verktyg för utveckling och tester. Här är de vanligaste scenarierna:

• Integrationstester: producera förutsägbara JWT:er för att driva E2E-tester som angriper skyddade endpoints utan att vara beroende av den riktiga identitetsleverantören.
• API-mockar: tillfälligt ersätta ett anrop till IdP:n med en JWT signerad lokalt med samma testhemlighet.
• Lokal utveckling: ansluta till sin egen backend genom att manuellt generera en token som innehåller önskade claims, utan att behöva gå igenom hela OAuth2-flödet.
• Demos: illustrera ett autentiseringsförlopp eller ett behörighetsbaserat workflow utan att ha en riktig IdP till hands.
• Buggreproduktion: smida en utgången token, en token med felaktigt aud, en token utan vissa claims, för att testa ditt API:s felvägar.
• Debug av en custom-parser: injicera specialbyggda JWT:er för att testa en egenutvecklad parser.

En JWT:s sammansättning

En signerad JWT består av tre segment separerade med en punkt, var och en kodad i Base64URL (variant av Base64 utan padding och med -/_ i stället för +//):

• Header: ett JSON-objekt som beskriver signaturalgoritmen och tokenens typ, till exempel {"alg":"HS256","typ":"JWT"}. JWT Builder genererar den automatiskt utifrån den algoritm du väljer.
• Payload: ett godtyckligt JSON-objekt som innehåller tokenens claims (subject, behörigheter, utgångsdatum). Det är den del du tillhandahåller.
• Signatur: en HMAC-SHA beräknad på konkateneringen base64url(header) + "." + base64url(payload) med din hemliga nyckel. Det är den som garanterar tokenens integritet.

Användningsfall i detalj

• API-mock för E2E-tester: din Cypress- eller Playwright-svit behöver anropa ett API som kräver en Authorization: Bearer .... I stället för att orkestrera en fullständig inloggning vid varje test, signerar man en JWT i farten med den delade hemligheten och injicerar den i headern.
• SSO-demo: presentera ett federerat autentiseringsförlopp utan att vara beroende av en IdP online.
• Testfixtur: generera en deterministisk JWT från en känd payload för att tjäna som stabil fixtur i enhetstester.
• Diagnos av en egen parser: testa en hemmagjord JWT-parser med avsiktligt minimala eller avsiktligt konstiga tokens (saknade claims, oväntade typer).
• Lärande: konkret förstå hur en JWT byggs upp, genom att modifiera payloaden och observera hur signaturen ändras.

Algoritmer som stöds: HS256, HS384, HS512

Vårt verktyg stöder de tre standard-HMAC-algoritmerna från JWT-specifikationen (RFC 7519):

• HS256: HMAC med SHA-256. Signatur på 32 byte. Mest använd i praktiken, bra kompromiss mellan snabbhet och kryptografisk soliditet. Rekommenderad som standard.
• HS384: HMAC med SHA-384. Signatur på 48 byte. Anpassad för sammanhang som kräver en högre säkerhetsmarginal.
• HS512: HMAC med SHA-512. Signatur på 64 byte. Den mest robusta, till priset av en något större token.

HMAC eller RSA?

HS*-algoritmerna är symmetriska: samma nyckel används för att signera och verifiera. Det är enkelt och snabbt, men betyder att varje tjänst som kan verifiera en token också kan utfärda den. Om du behöver separera dessa två roller (en enda utfärdare, flera konsumenter), gå mot RS256/RS384/RS512-algoritmerna (RSA, asymmetriska), som du kan verifiera med vår JWT-verifier.

Säkerhet: skydda din hemlighet

Säkerheten i en HMAC-signerad JWT bygger helt på hemlighetens konfidentialitet. Några grundregler:

• Använd en lång och slumpmässig hemlighet. RFC 7518 rekommenderar minst storleken på algoritmens utdata (32 byte för HS256, 48 för HS384, 64 för HS512). Ett mänskligt lösenord som azerty123 är trivialt att knäcka offline.
• Signera aldrig en JWT på klientsidan. Hemligheten skulle hamna i den JavaScript-kod som distribueras till webbläsaren, exponerad för alla användare. Signaturen ska alltid stanna på serversidan.
• Lagra hemligheten i en miljövariabel (t.ex. JWT_SECRET), aldrig i ett Git-repo. Tänk på att använda ett valv som HashiCorp Vault, AWS Secrets Manager eller Symfony Secrets beroende på din stack.
• Rotera hemligheten regelbundet (key rotation), särskilt efter incident eller om någon med tillgång till konfigurationen slutar.
• JWT Builder är avsedd för tester och lärande. För produktion, använd JWT-biblioteket i ditt ramverk (lcobucci/jwt, firebase/php-jwt, jose-php).

Bästa praxis för claims

Payloaden är ett fritt JSON-objekt, men RFC 7519 definierar en uppsättning registered claims som JWT-bibliotek kan tolka. Att inkludera rätt claims gör din token portabel och undviker subtila buggar:

• iss (issuer): utfärdarens identifierare, till exempel "https://api.example.com".
• sub (subject): identifierare för den person eller entitet som berörs, ofta användarens ID.
• aud (audience): vem tokenen är avsedd för, för att förhindra återanvändning av en token på ett annat API.
• exp (expiration time): Unix-timestamp efter vilken tokenen inte längre är giltig. Inkludera alltid, även för en testtoken: en token utan utgång är en dålig vana som är svår att rätta till senare.
• nbf (not before): timestamp före vilken tokenen ännu inte är giltig. Användbar för att förhandsutfärda en token som aktiveras senare.
• iat (issued at): utfärdande-timestamp, användbar för loggning och revokering.
• jti (JWT ID): tokenens unika identifierare, oumbärlig för idempotens och för att implementera en revokeringslista.

Exempel på typisk payload

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

Så använder du verktyget

1. Ange payloaden som giltig JSON. Det är ett objekt, så det börjar med { och slutar med }.
2. Ange HMAC-hemligheten. Välj en lång och slumpmässig sträng för produktionstokens.
3. Välj algoritm: HS256 som standard, HS384 eller HS512 efter dina behov.
4. Klicka på skapa. Den signerade JWT:n visas, redo att klistras in i en header Authorization: Bearer ....
5. Du kan sedan verifiera tokenen med samma hemlighet för att bekräfta round-trip-konsistensen, eller avkoda den för att läsa om dess innehåll.

Vanliga frågor

Exempelförfrågan

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

Indatasschema

Slutpunkter

• GET https://cdrn.fr/api/v1/tools - listar alla tillgängliga verktyg
• GET https://cdrn.fr/api/v1/tools/jwt-builder - hämtar schemat för detta verktyg
• POST https://cdrn.fr/api/v1/tools/jwt-builder/execute - kör detta verktyg med en JSON-payload