JSON Web Token - JSON Web Token

JSON Web Token
Status Foreslået standard
Først udgivet 28. december 2010 ( 2010-12-28 )
Nyeste version RFC  7519
maj 2015
Organisation IETF
Forkortelse JWT

JSON Web Token ( JWT , udtalt / dʒ ɒ t / , samme som ordet "jot") er en foreslået internetstandard til oprettelse af data med valgfri signatur og / eller valgfri kryptering, hvis nyttelast har JSON, der hævder et antal krav . Tokens signeres enten ved hjælp af en privat hemmelighed eller en offentlig/privat nøgle .

For eksempel kan en server generere et token, der har påstanden "logget ind som administrator" og give det til en klient. Klienten kunne derefter bruge dette token til at bevise, at den er logget ind som admin. Tokens kan underskrives af en parts private nøgle (normalt serverens), så partiet efterfølgende kan kontrollere, at tokenet er legitimt. Hvis den anden part på en passende og pålidelig måde er i besiddelse af den tilhørende offentlige nøgle, kan de også verificere tokenets legitimitet. De tokens er designet til at være kompakt, URL -sikkert, og anvendelige især i en web-browser single-sign-on (SSO) kontekst. JWT -krav kan typisk bruges til at videregive godkendte brugeres identitet mellem en identitetsudbyder og en tjenesteudbyder eller enhver anden form for krav som krævet af forretningsprocesser.

JWT er afhængig af andre JSON-baserede standarder: JSON Web Signature og JSON Web Encryption .

Struktur

Header
 
{
  "alg": "HS256",
  "typ": "JWT"
}
Identificerer hvilken algoritme der bruges til at generere signaturen

HS256 angiver, at dette token er signeret ved hjælp af HMAC-SHA256.

Typiske anvendte kryptografiske algoritmer er HMAC med SHA-256 (HS256) og RSA-signatur med SHA-256 (RS256). JWA (JSON Web Algorithms) RFC 7518 introducerer mange flere til både godkendelse og kryptering.

Nyttelast
 
{
  "loggedInAs": "admin",
  "iat": 1422779638
}
Indeholder et sæt krav. JWT -specifikationen definerer syv registrerede kravnavne, som er standardfelterne, der almindeligvis er inkluderet i tokens. Brugerdefinerede krav er normalt også inkluderet, afhængigt af formålet med token.

Dette eksempel har standardkravet Issued At Time ( iat) og et brugerdefineret krav ( loggedInAs).

Underskrift
 
HMAC_SHA256(
  secret,
  base64urlEncoding(header) + '.' +
  base64urlEncoding(payload)
)
Validerer tokenet sikkert. Signaturen beregnes ved at kode overskriften og nyttelasten ved hjælp af Base64url Encoding RFC  4648 og sammenkoble de to sammen med en periodeseparator. Denne streng køres derefter gennem den kryptografiske algoritme, der er angivet i overskriften, i dette tilfælde HMAC-SHA256. Den Base64url Encoding ligner base64 , men bruger forskellige ikke-alfanumeriske tegn og undlader polstring.

De tre dele er kodet separat ved hjælp af Base64url Encoding RFC  4648 og sammenkædet med perioder til fremstilling af JWT: 

const token = base64urlEncoding(header) + '.' + base64urlEncoding(payload) + '.' + base64urlEncoding(signature)

Ovenstående data og hemmeligheden bag "secretkey" skaber token: 

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLyMyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJyJySuJyJySuJySuJySuJySuJySuJySjMyJyJyJySjJyJyJyJySjMySjSjJyJjSjJyJyJjSjJsyJy

Dette resulterende token kan let overføres til HTML og HTTP .

Brug

Ved godkendelse, når brugeren logger ind med sine legitimationsoplysninger, returneres et JSON Web Token og skal gemmes lokalt (typisk i lokal eller sessionslagring , men cookies kan også bruges), i stedet for den traditionelle tilgang til at oprette en session på serveren og returnere en cookie. Ved uovervåget processer kan klienten også autentificere direkte ved at generere og underskrive sin egen JWT med en på forhånd delt hemmelighed og videregive den til en OAuth- kompatibel service som sådan:

POST /oauth2/token?
Content-type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=eyJhb...

Hvis klienten passerer en gyldig JWT -påstand, vil serveren generere en access_token, der er gyldig til at foretage opkald til applikationen og videresende den til klienten:

{
  "access_token": "eyJhb...",
  "token_type": "Bearer",
  "expires_in": 3600
}

Når klienten ønsker at få adgang til en beskyttet rute eller ressource, skal brugeragenten sende JWT, typisk i Authorizationoverskriften ved hjælp af Bearerskemaet. Indholdet af overskriften kan se sådan ud: 

Authorization: Bearer eyJhbGci...<snip>...yu5CSpyHI

Dette er en statsløs godkendelsesmekanisme, da brugerstatus aldrig gemmes i serverhukommelse. Serverens beskyttede ruter søger efter en gyldig JWT i autorisationsoverskriften, og hvis den er til stede, får brugeren adgang til beskyttede ressourcer. Da JWT'er er uafhængige, er alle de nødvendige oplysninger der, hvilket reducerer behovet for at forespørge databasen flere gange.

Standardfelter

kode navn beskrivelse
Standardkravsfelter Internetudkast definerer følgende standardfelter ("krav"), der kan bruges inde i et JWT -kravsæt.
iss Udsteder Identificerer hovedstol, der udstedte JWT.
sub Emne Identificerer emnet for JWT.
aud Publikum Identificerer de modtagere, som JWT er beregnet til. Hver hovedstol, der er beregnet til at behandle JWT, skal identificere sig med en værdi i publikumskravet. Hvis den primære behandling er påstanden ikke identificere sig selv med en værdi i audkravet, når denne påstand er til stede, så JWT må afvises.
exp Udløbstid Identificerer udløbstiden, hvorefter JWT ikke må accepteres til behandling. Værdien skal være en NumericDate: enten et heltal eller decimal, der repræsenterer sekunder efter 1970-01-01 00: 00: 00Z .
nbf Ikke før Identificerer det tidspunkt, hvor JWT vil begynde at blive accepteret til behandling. Værdien skal være en NumericDate.
iat Udstedt kl Identificerer det tidspunkt, hvor JWT blev udstedt. Værdien skal være en NumericDate.
jti JWT ID Kassefølsom unik identifikator for token, selv blandt forskellige udstedere.
Almindeligt anvendte overskriftsfelter Følgende felter bruges normalt i overskriften på en JWT
typ Token type Hvis det findes, anbefales det at indstille dette til JWT.
cty Indholdstype Hvis der bruges indlejret signering eller kryptering, anbefales det at indstille dette til JWT; ellers skal du udelade dette felt.
alg Meddelelsesgodkendelse -algoritme Udstederen kan frit indstille en algoritme til at verificere signaturen på token. Nogle understøttede algoritmer er imidlertid usikre.
kid Nøgle -id Et tip, der angiver hvilken nøgle klienten brugte til at generere token signaturen. Serveren vil matche denne værdi til en nøgle i filen for at kontrollere, at signaturen er gyldig og tokenet er autentisk.
x5c x.509 Certifikatkæde En certifikatkæde i RFC4945 -format svarende til den private nøgle, der bruges til at generere token -signaturen. Serveren vil bruge disse oplysninger til at kontrollere, at signaturen er gyldig og tokenet er autentisk.
x5u x.509 Certificate Chain URL En URL, hvor serveren kan hente en certifikatkæde, der svarer til den private nøgle, der bruges til at generere token signaturen. Serveren henter og bruger disse oplysninger til at kontrollere, at signaturen er autentisk.
crit Kritisk En liste over overskrifter, der skal forstås af serveren for at acceptere tokenet som gyldigt
kode navn beskrivelse

Implementeringer

JWT -implementeringer findes på mange sprog og rammer, herunder men ikke begrænset til:

Sårbarheder

JSON web tokens kan indeholde sessionstilstand. Men hvis projektkrav tillader sessionens ugyldighed før JWT -udløb, kan tjenester ikke længere stole på token -påstande af token alene. For at validere, at den session, der er gemt i token, ikke tilbagekaldes, skal token -påstande kontrolleres mod et datalagring . Dette gør tokens ikke længere statsløse, hvilket undergraver den primære fordel ved JWT'er.

Sikkerhedskonsulent Tim McLean rapporterede sårbarheder i nogle JWT -biblioteker, der brugte algfeltet til forkert at validere tokens, oftest ved at acceptere et alg=nonetoken. Mens disse sårbarheder blev korrigeret, foreslog McLean alghelt at afskrive feltet for at forhindre lignende implementeringsforvirring. Alligevel alg=nonefindes der stadig nye sårbarheder i naturen, med fire CVE'er indgivet i perioden 2018-2021 med denne årsag.

Med korrekt design kan udviklere løse algoritmesårbarheder ved at tage forholdsregler:

  1. Lad aldrig JWT -headeren alene køre verifikation
  2. Kend algoritmerne (undgå afhængigt af algfeltet alene)
  3. Brug en passende nøglestørrelse

Se også

Referencer

eksterne links