Pārbaudīt JSON Web Token (JWT) parakstu

Kāpēc pārbaudīt JWT parakstu?

JSON tīmekļa pilnvara (JWT) ir sadalīta trīs daļās, kas atdalītas ar punktiem. header.payload.signature. JWT atšifrēšana ir tikai pirmo divu nolasīšanas jautājums daļas (kas ir Base64URL). Ikviens var to izdarīt, un ikviens varizdarīt JWT ar jūsu izvēlētu kravnesību. Tas, kas padara JWT uzticamu, ir tikai tas paraksts: bez verifikācijas JWT pieņemšana nozīmē ļaut savās mājās ikvienu, kurš uzdodas par kādu, neprasot identifikāciju.

Šis rīks pārbauda parakstu JWT no atslēgas. Viņš nav apmierināts ar atšifrēt: tas pārrēķina parakstu no galvenes, lietderīgās slodzes un jūsu atslēgas, pēc tam salīdzina to ar žetonu parakstu. Ja abi sakrīt, marķieris ir autentisks. Citādi tas bija viltots, modificēts vai parakstīts ar citu atslēgu.

Verifikācija ir jebkuras arhitektūras stūrakmens, kurā tiek izmantoti JWT autentifikācija vai autorizācija: bez derīga paraksta var būt lietderīga slodze. Uzbrucējam, kurš maina "role":"user" uz "role":"admin", nav grūtības to izdarīt, ja serveris pārbaudīja tikai marķiera formātu, nevis tā parakstu.

Izplatīti algoritmi

JWT specifikācija (RFC 7518, JSON Web Algorithms) nosaka vairākas algoritmu grupas. Šeit ir visvairāk izmanto ražošanā:

• HMAC (HS256, HS384, HS512): simetrisks paraksts, kura pamatā ir HMAC-SHA. The Parakstīšanai un verifikācijai tiek izmantota tā pati slepenā atslēga. Vienkārši uzstādāms, efektīva, taču jebkura puse, kas spēj pārbaudīt marķieri, var arī to izsniegt. Pielāgots scenārijiem, kuros izdevējs un verificētājs ir viena un tā pati komanda vai nodaļa.
• RSA (RS256, RS384, RS512): asimetrisks paraksts. Privātā atslēga zīmi, publiskā atslēga pārbauda. Ideāli, kad raidītājs un Verificētāji ir atsevišķas entītijas (OAuth2, OpenID Connect, Identity Federation). Tas ir algoritms, ko iecienījuši lielākā daļa publiskās identitātes nodrošinātāju.
• ECDSA (ES256, ES384): asimetrisks paraksts uz eliptiskām līknēm. Tāda pati loģika kā RSA (privātā atslēga parakstīšanai, publiskā atslēga verifikācijai), bet ar atslēgām un kompaktāki paraksti līdzvērtīgam drošības līmenim. Aizvien plašāk izplatīts in modernās arhitektūras.

Kā nodrošināt atslēgu

Paredzamās atslēgas formāts ir atkarīgs no JWT galvenē deklarētā algoritma:

• HS256, HS384, HS512: atslēga ir slepenā virkne (virkne). Šis ir noslēpums, kas tiek kopīgots ar emitentu, un tas bieži tiek glabāts vides mainīgajā, piemēram, JWT_SECRET. Bez īpaša formatējuma, tikai neapstrādātā vērtība.
• RS256, RS384, RS512: atslēga ir RSA publiskā atslēga PEM formātā, kas sākas ar -----BEGIN PUBLISKĀ ATSLĒGA----- un beidzas ar -----BEIGAS PUBLISKĀ ATSLĒGA-----. Saglabājiet jaunās rindiņas kā ir, pretējā gadījumā OpenSSL atsakās to parsēt.
• ES256, ES384: atslēga ir ECDSA publiskā atslēga PEM formātā, uz atbilstošās līknes (P-256 ES256, P-384 ES384).

Paredzamās RSA publiskās atslēgas piemērs

-----SĀKT PUBLISKO ATSLĒGU-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx...
...vQIDAQAB
-----PUBLISKĀ ATSLĒGA BEIGAS-----

Kā darbojas verifikācija?

Mūsu serveris precīzi atveido raidītāja veikto darbību:

1. Tas sadala JWT galvenē, lietderīgajā slodzē un parakstā.
2. Tas savieno base64url(header) + "." + base64url(lietderīgā slodze).
3. HMAC tas aprēķina HMAC-SHA-256/384/512 ar jūsu slepeno atslēgu, pēc tam salīdzina ar paraksts, kas saņemts, izmantojot hash_equals (pastāvīgs laika salīdzinājums, lai izvairītos no uzbrukumiem laiks).
4. RSA gadījumā tas izsauc openssl_verify ar jūsu publisko atslēgu PEM formātā.

Lietošanas gadījumi

• API autentifikācijas atkļūdošana: saņemat 401. pārbaudiet, vai jūsu pilnvara ir labi parakstīts ar paredzēto atslēgu.
• No piegādātāja saņemtā marķiera validācija: partneris (Auth0, Keycloak, Cognito, Okta) nosūta jums JWT, kas parakstīti RS256; vēlaties apstiprināt, ka tie nāk no ar savu publisko atslēgu.
• Drošības audits: pārbaudiet, vai trešās puses pakalpojums pareizi paraksta savus marķierus. ar stabilu algoritmu, nevis HS256 ar zemu slepenību.
• Manuālie testi: pārbaudiet, vai jūsu koda ģenerētais JWT iztur verifikācija ar sniegto publisko atslēgu.
• Ātrā saņemtā marķiera pārbaude: SSO vai Partnera API, pirms dažām sekundēm pārbaudiet, vai paraksts/atslēgu ķēde darbojas lai uzrakstītu vismazāko koda rindiņu.

Kā lietot rīku

1. Ielīmējiet visu JWT (trīs daļas, kas atdalītas ar punktiem).
2. Norādiet atslēgu, kas pielāgota galvenes algoritmam:
   • Sistēmai HS256, HS384 vai HS512 atslēga ir slepenā virkne koplietotar raidītāju. Tā ir brīva virkne, kas bieži tiek glabāta a vides mainīgais, piemēram, JWT_SECRET.
   • Sistēmai RS256, RS384 vai RS512 atslēga ir publiskā atslēga šādā formātā PEM, kas sākas ar -----BEGIN PUBLISKĀ ATSLĒGA----- un beidzas ar -----BEIGAS PUBLISKĀ ATSLĒGA-----.
3. Palaidiet pārbaudi. Rīks parāda statusu (derīgu vai nederīgu) un dekodēto lietderīgo slodzi.

Bieži sastopamās nepilnības, no kurām jāizvairās

• Algoritms "none": specifikācija atļauj alg: none, kas nozīmē "nē". paraksts". Klasisks trūkums ir marķiera izveide ar šo galveni, cerot, ka serveris to pieņem. Mūsu rīks sistemātiski noraida marķierus ar alg: nav.
• HMAC un RSA apjukums (algoritmu apjukums): uzbrucējs maina algoritmu RS256 uz HS256 un paraksta lietderīgo slodzi ar izmantoto RSA publisko atslēgu kā HMAC noslēpums. Ja serveris nekontrolē algoritmu, tas pieņem marķieri. Vienmēr bloķējiet paredzēto algoritmu servera pusē.
• Cietie kodēti HMAC noslēpumi: tiek renderēts Git repozitorijā izdarīts noslēpums visa uzticība žetoniem ir zudusi. Glabājiet noslēpumus vides mainīgajos vai lietojumprogrammu seifs.
• Publiskā atslēga pret privāto atslēgu: lai pārbaudītu JWT, kas ir pierakstījies RSA vai ECDSA, mēs nodrošina publisko atslēgu, nevis privāto. Privātais tiek izmantots tikai parakstīšanai un netiek izmantots nekad nedrīkst izkļūt no raidītāja.
• Ignorēts derīguma termiņš: derīgam parakstam uz marķiera, kuram beidzies derīguma termiņš, nevajadzētu būt nekad netiktu pieņemts. Atcerieties atzīmēt exp un nbf.
• Nekontrolēta auditorija: marķieri, kas paredzēti API A, nedrīkst tikt pieņemti izmantojot API B. Pārbaudiet pretenziju aud.

Pretenzijas uz laiku: exp un nbf

Papildus parakstam derīgam JWT ir jāievēro arī laika ierobežojumi:

• derīguma termiņš (derīguma termiņš): pēc šī datuma marķieris vairs nav derīgs.
• nbf (ne agrāk): marķieris vēl nav derīgs pirms šī datuma.

Mūsu rīks skaidri norāda, kad marķieris ir beidzies vai vēl nav derīgspat ja viņa paraksts ir pareizs. Tas ir svarīgi: derīgs paraksts uz a Token, kuram beidzies derīguma termiņš, nekad nevajadzētu pieņemt ražošanā.

Atšķirība ar mūsu JWT dekodētāju

Mūsu JWT dekodētājs tikai atkodē galveni un kravnesība, lai tās būtu lasāmas. Tas neveic paraksta verifikāciju un neprasi atslēgu. Izmantojiet to, lai ātri pārbaudītu marķiera saturu. Izmantojiet JWT verificētājs (šī lapa) ikreiz, kad jāpierāda, ka marķieris ir autentisks. Lai testēšanai izveidotu parakstītu JWT, izmantojiet mūsu JWT veidotājs.

Bieži uzdotie jautājumi

Pieprasījuma piemērs

curl -X POST https://cdrn.fr/api/v1/tools/jwt-verifier/execute \
  -H "Content-Type: application/json" \
  -d '{"token":"...","key":"..."}'

Ievades shēma

Endpoint

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