Izveidot parakstītu JSON Web Token (JWT)

Kas ir JWT Builder?

JWT Builder ir tiešsaistes rīks, kas izveido parakstītu JSON tīmekļa pilnvaru. (JWT) no JSON derīgās slodzes un HMAC noslēpuma. Tas ir paredzēts izstrādātājiem, kuriem tas ir nepieciešams lai ātri ģenerētu testa marķieri API darbības pārbaudei, simulējiet sesiju autentificēts pakalpojumā Postman vai reproducēt kļūdu, kas saistīta ar marķiera derīguma termiņu vai darbības jomu.

Atšķirībā no mūsu JWT dekodētāja, kas tikai nolasa pilnvaru esošais, JWT Builder izveido pilnīgu pilnvaru: tas veido galveni, kodē lietderīgā slodze, aprēķina HMAC parakstu un visu apkopo kompaktā formātā header.payload.signature gaida visas JWT bibliotēkas tirgū.

Kāpēc izveidot JWT?

JWT veidotājs nav paredzēts ražošanas žetonu izdošanai. Tas galvenokārt ir rīks izstrāde un testēšana. Tālāk ir norādīti visizplatītākie scenāriji.

• Integrācijas testi: izveidojiet paredzamus JWT, lai vadītu E2E testus kas sasniedza aizsargātos galapunktus, nepaļaujoties uz īsto identitātes nodrošinātāju.
• API izspēles: īslaicīgi aizstājiet zvanu uz IDP ar parakstītu JWT lokāli ar to pašu testa noslēpumu.
• Vietējā attīstība: izveidojiet savienojumu ar savu aizmugursistēmu, manuāli ģenerējot a marķieris, kas satur vēlamās pretenzijas, bez nepieciešamības iziet cauri visai OAuth2 plūsmai.
• Demonstrācijas: ilustrējiet autentifikācijas ceļu vai darbplūsmu, pamatojoties uz atļaujas bez īstas IDP.
• Kļūdu pavairošana: viltojiet marķieri, kuram beidzies derīguma termiņš, vai marķieri ar Nepareizs aud, marķieris bez noteiktiem apgalvojumiem, lai pārbaudītu kļūdu ceļus jūsu API.
• Pielāgota parsētāja atkļūdošana: ievadiet JWT, kas īpaši konstruēti pārbaudiet paštaisītu parsētāju.

JWT sastāvs

Parakstīts JWT sastāv no trim segmentiem, kas atdalīti ar punktu un katrs ir iekodēts Base64URL (Base64 variants bez polsterējuma un ar -/_ +// vietā):

• Galvene: JSON objekts, kas apraksta paraksta algoritmu un pilnvaras veidu, piemēram, {"alg":"HS256","typ":"JWT"}. JWT Builder to automātiski ģenerē no no jūsu izvēlētā algoritma.
• Payload: patvaļīgs JSON objekts, kas satur marķiera pretenzijas (tēma, atļaujas, derīguma termiņi). Šī ir jūsu sniegtā daļa.
• Paraksts: HMAC-SHA, kas aprēķināts pēc savienošanas base64url(header) + "." + base64url(payload) ar savu slepeno atslēgu. Tā ir viņa garantē marķiera integritāti.

Detalizēti lietošanas gadījumi

• API izspēles E2E testēšanai: jūsu Cypress vai Playwright komplektam ir jāizsauc API kam nepieciešama autorizācija: nesējs .... Tā vietā, lai organizētu pilnīgu pieteikšanos vietnē katrā pārbaudē mēs lidojuma laikā parakstām JWT ar kopīgoto noslēpumu un ievadām to galvenē.
• SSO demonstrācija: piedāvājiet apvienoto autentifikācijas ceļu bez atkarības tiešsaistes IDP.
• Testēšanas iekārta: ģenerējiet deterministisku JWT no derīgās slodzes, kas zināma kalpo kā stabils elements vienību testos.
• Pielāgota parsētāja diagnostika: paštaisīta JWT parsētāja pārbaude ar marķieriem apzināti minimāls vai apzināti dīvains (trūkst pretenziju, neparedzēti veidi).
• Mācīšanās: precīzi izprotiet, kā tiek veidots JWT modificējot lietderīgo slodzi un vērojot, kā mainās paraksts.

Atbalstītie algoritmi: HS256, HS384, HS512

Mūsu rīks atbalsta trīs JWT specifikācijas standarta HMAC algoritmus (RFC 7519):

• HS256: HMAC ar SHA-256. 32 baitu paraksts. Visbiežāk izmanto praksē, labs kompromiss starp ātrumu un kriptogrāfisko stabilitāti. Ieteicams pēc noklusējuma.
• HS384: HMAC ar SHA-384. 48 baitu paraksts. Pielāgots kontekstam, kas nepieciešama lielāka drošības rezerve.
• HS512: HMAC ar SHA-512. 64 baitu paraksts. Visizturīgākais, par cenu nedaudz lielāka marķiera.

HMAC vai RSA?

HS* algoritmi ir simetriski: parakstīšanai un pārbaudei tiek izmantota viena un tā pati atslēga. Tas ir ātri un vienkārši, taču tas nozīmē, ka jebkurš pakalpojums, kas var pārbaudīt marķieri, arī ir tāds spēj tās izstarot. Ja nepieciešams nošķirt šīs divas lomas (viens izdevējs, vairākas patērētāji), izmantojiet RS256/RS384/RS512 algoritmus (RSA, asimetrisks), kuru varat pārbaudīt, izmantojot mūsu JWT verificētāju.

Drošība: aizsargājiet savu noslēpumu

HMAC parakstīta JWT drošība ir pilnībā atkarīga no noslēpuma konfidencialitātes. Daži pamatnoteikumi:

• Izmantojiet garu, nejaušu noslēpumu. RFC 7518 iesaka vismaz izmēru no algoritma izejas (32 baiti HS256, 48 HS384, 64 HS512). Parole Cilvēks, piemēram, azerty123, bezsaistē var uzbrukt triviāli brutālu spēku.
• Nekad neparakstiet klienta puses JWT. Noslēpums būtu atrodams kodā JavaScript tiek izplatīts pārlūkprogrammā un ir pieejams jebkuram lietotājam. Parakstam vienmēr ir jāpaliek servera pusē.
• Saglabājiet noslēpumu vides mainīgajā (piemēram, JWT_SECRET), nekad nav Git repozitorijā. Apsveriet iespēju izmantot glabātuvi, piemēram, HashiCorp Vault, AWS Secrets Manager vai Symfony Secrets atkarībā no jūsu steka.
• Regulāri pagrieziet noslēpumu (atslēgas rotācija), īpaši pēc jebkāda negadījuma vai personas, kurai bija piekļuve konfigurācijai, aiziešana.
• JWT Builder ir paredzēts testēšanai un mācībām. Ražošanai, izmantojiet savas sistēmas JWT bibliotēku (lcobucci/jwt, firebase/php-jwt, jose-php).

Laba prasījumu iesniegšanas prakse

Lietderīgā slodze ir bezmaksas JSON objekts, bet RFC 7519 definē reģistrētu pretenziju kopu. ka JWT bibliotēkas zina, kā interpretēt. Pareizo pretenziju iekļaušana padara jūsu marķieri pārnēsājamu un novērš smalkas kļūdas:

• iss (izdevējs): emitenta identifikators, piemēram, "https://api.example.com".
• subjekts (subject): attiecīgās personas vai vienības identifikators, bieži vien ID lietotājs.
• audi (auditorija): kam marķieris ir paredzēts, lai novērstu atkārtotu marķieris citā API.
• termiņš (derīguma termiņš): Unix laikspiedols, pēc kura marķieris vairs nav derīgs. Vienmēr iekļaut, pat testa pilnvarai: pilnvara bez derīguma termiņa beigām ir a slikto ieradumu ir grūti pēc tam labot.
• nbf (ne agrāk): laikspiedols, pirms kura marķieris vēl nav derīgs. Noderīga marķiera iepriekšējai izdošanai, ko var aktivizēt vēlāk.
• iat (izdošanas datums): izdošanas laikspiedols, noder reģistrēšanai un atsaukšanai.
• jti (JWT ID): unikāls marķiera identifikators, kas ir būtisks idempotence un ieviest atsaukšanas sarakstu.

Tipisks lietderīgās kravas piemērs

{
  "iss": "https://api.example.com",
  "sub": "lietotājs-12345",
  "aud": "mobilā lietotne",
  "iat": 1714723200,
  "exp": 1714726800,
  "jti": "9f2d6b1e-2c4a-4f8a-9c3a-87a2b8a4b7e1",
  "scope": "lasīt:profils rakstīt:profils"
}

Kā lietot rīku

1. Ievadiet derīgo slodzi kā derīgu JSON. Tas ir objekts, tāpēc tas sākas ar { un beidzas ar }.
2. Norādiet HMAC noslēpumu. Izvēlieties garu, nejaušu virkni ražošanas marķieriem.
3. Atlasiet algoritmu: HS256 pēc noklusējuma, HS384 vai HS512 atbilstoši savām vajadzībām.
4. Noklikšķiniet uz izveidot. Parādās parakstīts JWT, kas ir gatavs ielīmēšanai galvenē Autorizācija: nesējs....
5. Pēc tam varat verificēt marķieri ar to pašu noslēpumu apstipriniet ceļojuma konsekvenci vai atkodējiet, lai lasītu atkārtoti tā saturs.

Bieži uzdotie jautājumi

Pieprasījuma piemērs

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

Ievades shēma

Endpoint

• GET https://cdrn.fr/api/v1/tools - uzskaita visus pieejamos rīkus
• GET https://cdrn.fr/api/v1/tools/jwt-builder - iegūst šī rīka shēmu
• POST https://cdrn.fr/api/v1/tools/jwt-builder/execute - izpilda šo rīku ar JSON payload