Forståelse av JWT-validering: En praktisk guide med kodeeksempler

JSON Web Tokens (JWT) er en sikker og standardisert metode for lagring og utveksling av data i JSON-format. Til tross for at JWT-er har fått stor utbredelse i moderne nettutvikling, krever en robust implementering av JWT-er kunnskap og nøye håndtering for å sikre optimal sikkerhet. Dette bringer oss til temaet JWT-validering.

I denne artikkelen skal vi diskutere dette:

• Hvordan sikrer vi at et JWT-token er til å stole på og ikke har blitt tuklet med?
• Hva innebærer JWT-validering, og hvilke tokenelementer valideres?
• Hvordan du utfører JWT-validering.

JWT-er kan også krypteres for konfidensialitet (se JSON Web Encryption, JWE), men her fokuserer vi på signerte tokens(JSON Web Signature, JWS). Krypterte tokens holder informasjonen de inneholder, skjult for eksterne parter. Signerte tokens skjuler derimot ikke informasjonen, men tilbyr bevis på dataintegritet gjennom validering. Derfor er valideringstrinnet avgjørende når du arbeider med signerte JWT-er.

Vi bruker et JWT-token utstedt av Idura Verify for å vise tokenstrukturen og elementene som krever validering.

En innføring i JWT-er

JWT-er er mye brukt til å håndtere identitet, autentisering og autorisasjon. JWT-basert brukerautentisering har blitt en standardpraksis, spesielt fordi den integreres så enkelt med mobilapplikasjoner og SPA-er. JWT-er brukes også ofte som tilgangstokener og ID-tokener i OAuth2- og OpenID Connect-flyter.

Demonstrasjon: et JWT-token i en OpenID Connect-flyt

Tenk deg en OpenID Connect-flyt der en bruker logger seg på en webapplikasjon med en elektronisk ID (eID). Idura Verify fungerer som en OpenID-leverandør for påloggingsprosessen: Ved vellykket autentisering utsteder den et ID-token formatert som en JWT til klientapplikasjonen. (Mer spesifikt vil domenet ditt hos Idura fungere som en OpenID-leverandør).

Når en bruker for eksempel logger inn med dansk MitID, mottar applikasjonen et ID-token som kan se slik ut:

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjhCREY3OUEzRkY5OTdFQTg1QjYyRjk1OUQzRDdCMzdFRDAyMjhFOTAifQ.eyJpc3MiOiJodHRwczovL2RlbW9zLXRlc3QuY3JpaXB0by5pZCIsImF1ZCI6InVybjpkZW1vczpjb29sLWRlbGl2ZXJ5LXJlYWN0IiwiaWRlbnRpdHlzY2hlbWUiOiJka21pdGlkIiwiYXV0aGVudGljYXRpb250eXBlIjoidXJuOmdybjphdXRobjpkazptaXRpZDpzdWJzdGFudGlhbCIsImF1dGhlbnRpY2F0aW9ubWV0aG9kIjoiYXBwOjE3MDUzMjQ5MjYxNTM6U1VCU1RBTlRJQUw6U1VCU1RBTlRJQUw6SElHSDpISUdIIiwiYXV0aGVudGljYXRpb25pbnN0YW50IjoiMjAyNC0wMS0xNVQxMzoyMjowNy44MDFaIiwibmFtZWlkZW50aWZpZXIiOiJiYWQwZmJiMmRmM2Q0Yzg3YTU5OGRjZDcyYTJlYWRjMCIsInN1YiI6IntiYWQwZmJiMi1kZjNkLTRjODctYTU5OC1kY2Q3MmEyZWFkYzB9Iiwic2Vzc2lvbmluZGV4IjoiYjRiMmE1ZjctMTM1Ni00YjhkLTliZjMtZTFlNjIzOWEzOTJlIiwibG9BIjoiU1VCU1RBTlRJQUwiLCJpYWwiOiJTVUJTVEFOVElBTCIsImFhbCI6IlNVQlNUQU5USUFMIiwiZmFsIjoiSElHSCIsInV1aWQiOiJkNWVhNjMzMS02ZGU0LTQ5ZTktODUyYy0xNDE1YjMxNTM3YzIiLCJiaXJ0aGRhdGUiOiIxOTk1LTAzLTAyIiwiZGF0ZW9mYmlydGgiOiIxOTk1LTAzLTAyIiwiYWdlIjoiMjgiLCJuYW1lIjoiS2FqIEFuZGVyc2VuIiwicmVmVGV4dEhlYWRlciI6IkxvZyBvbiBhdCBDcmlpcHRvIChURVNUKSIsInJlZlRleHRCb2R5IjoiTG9nIGluIHRvIENvb2wgRGVsaXZlcnkiLCJjb3VudHJ5IjoiREsiLCJpYXQiOjE3MDUzMjQ5NDUsIm5iZiI6MTcwNTMyNDk0NSwiZXhwIjoxNzA1MzI2MTQ1fQ.O7QilOzcqLqRFCr9ij_bPS_hLXtJSZjufTLpNhtU_Oy8FmtHl88ErUsOMKPAgo2WJoCLwrtgLGlPKVzcQ66iUZwboza7bEJF9tQFWAvK1XEw7Fce_TztjsJrxDl-vue4ImjkBZQl-IToPg4egrq6gqXYBcWtWk4xZXRSMtQ4wNOX3gtlAyhDmiAbWwjFNGFzDJYP--sZvxU0MsvDNGzJwz0_JoZGEQoDkUYABxyp9syVyJv6Hock5QGzPMI5JmgPkSPrnRGV2ZnYaytRn1CdQcKIijlh61vwvOxffZBHnNkGXJxim8lOUtEyhDQO4fmnh_bLc2cxOl1hdkGHkgjoRQ

Det som ser ut som en tilfeldig tegnstreng, er i virkeligheten en kompakt, utskrivbar representasjon av et sett med påstander, ledsaget av en kryptografisk signatur. Påstandene inneholder informasjon om den autentiserte brukeren, og signaturen sikrer tokenets autentisitet: Siden tokenet er kryptografisk signert, er det enkelt å verifisere at det er legitimt og ikke har blitt tuklet med.

Prosessen med å validere påstandene og signaturen kalles tokenvalidering. Dette valideringstrinnet er obligatorisk: Hvis du ikke validerer signaturen, må du ikke stole på sluttbrukerinformasjonen.

La oss nå se nærmere på JWT-strukturen for å få en dypere forståelse av hva valideringen innebærer, og hvilke tokenelementer som valideres.

Oversikt over JWT-strukturen

Som definert i RFC 7519 består en signert JWT av tre segmenter atskilt med prikker:

• Header
• Nyttelast
• Signatur

Dette oppretter strukturen: header. payload. signature

Header- og payload-seksjonene inneholder JSON-data som er kodet ved hjelp av Base64Url. JWT-er er altså biter av Base64Url-kodede JSON-data med en kryptografisk signatur på slutten. Alle som har tilgang til en JWT, kan dekode tokenet og se informasjonen det inneholder. Du kan eksperimentere med dekoding på jwt.io - en interaktiv lekeplass for å lære mer om JWT-er. Kopier gjerne tokenet ovenfor og se resultatene. Legg merke til hva som skjer når du redigerer innholdet (Hint: Alle endringer i innholdet vil ugyldiggjøre signaturen).

La oss nå bryte ned hvert segment for å forstå dets rolle.

Overskrift

Headeren inneholder informasjon om token-typen og algoritmen som brukes til å generere signaturen. De vanligste signaturalgoritmene for JWT-er er RS256 (RSA med SHA256) og HS256 (HMAC med SHA256). JWT-er kan signeres ved hjelp av en delt hemmelighet (med HMAC-algoritmen) eller den private nøkkelen fra et offentlig-privat nøkkelpar (med RSA).

Det dekodede overskriften fra tokenet vårt ser slik ut:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "8BDF79A3FF997EA85B62F959D3D7B37ED0228E90"
}

Egenskapene her er

• "typ" for token-typen
• "alg" for signaturalgoritmen (Idura Verify bruker RSA til å signere JWT-er)
• "kid" (nøkkel-ID) identifiserer en offentlig nøkkel som skal brukes til verifisering i henhold til RSA-algoritmen.

Vi trenger denne informasjonen for å utføre tokenvalidering.

Nyttelast

Nyttelasten er sentral i en JWT: Den inneholder informasjon som tokenet er ment å transportere. Påstandene i nyttelasten inneholder data om brukeren som logget inn, for eksempel identitet, rolle eller systemtillatelser. Les mer om JWT-påstander i vårt tidligere blogginnlegg.

Det finnes tre typer JWT-påstander:

Registrerte påstander: Disse er definert av JWT-spesifikasjonen for å sikre interoperabilitet med tredjepartsapplikasjoner. Registrerte krav er ikke obligatoriske, men anbefales. Noen registrerte påstander er: iss (utsteder), exp (utløpstid), sub (emne), aud (publikum) og andre. Registrerte krav er nyttige for noen vanlige operasjoner som utføres med JWT-er, og de spiller en rolle i tokenvalidering, som demonstrert i neste økt.

Offentlige påstander: Dette er ikke-registrerte påstander som defineres etter eget ønske av partene som bruker JWT-er. Offentlige krav bør være universelt kollisjonsresistente: enten registrert i IANA-registeret "JSON Web Token Claims" eller ha et kollisjonsresistent navn.

Private påstander: Private påstander defineres på samme måte av partene som bruker JWT-er, men skiller seg fra offentlige påstander ved at de ikke trenger å være kollisjonsresistente. I vårt tokeneksempel er identityscheme og authenticationtype private påstander.

Den dekodede nyttelasten fra tokenet vårt ser slik ut (forkortet for å gjøre det kort, men du kan se den i sin helhet ved hjelp av jwt.io):

{
  "iss": "https://demos-test.idura.broker",
  "aud": "urn:demos:cool-delivery-react",
  "identityscheme": "dkmitid",
  "authenticationtype": "urn:grn:authn:dk:mitid:substantial",
  "authenticationinstant": "2024-01-15T13:22:07.801Z",
  "nameidentifier": "bad0fbb2df3d4c87a598dcd72a2eadc0",
  "sub": "{bad0fbb2-df3d-4c87-a598-dcd72a2eadc0}",
  "sessionindex": "b4b2a5f7-1356-4b8d-9bf3-e1e6239a392e",
  "loA": "SUBSTANTIAL",
  "uuid": "d5ea6331-6de4-49e9-852c-1415b31537c2",
  "birthdate": "1995-03-02",
  "dateofbirth": "1995-03-02",
  "age": "28",
  "name": "Kaj Andersen",
  "country": "DK",
  "iat": 1705324945,
  "nbf": 1705324945,
  "exp": 1705326145
}

Signatur

Når en OpenID Provider utsteder et token, signerer den det med en kryptografisk signatur.

Signaturen genereres ved å kombinere base64URL-kodede header- og payload-segmenter med en hemmelig eller privat nøkkel (avhengig av hvilken algoritme som er valgt).

For RSA256:

RSA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  private_key
)

For HMAC256:

HMAC256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

Som vist ovenfor kan JWT-er signeres ved hjelp av enten en delt hemmelighet (med HMAC) eller en privat nøkkel (med RSA).

Den nøyaktige signeringsprosessen innebærer å ta en hash av signeringsinndataene og deretter signere denne hashen. Denne artikkelen gir en utmerket detaljert forklaring av signeringsprosessen hvis du ønsker å fylle ut eventuelle hull i forståelsen din.

Det primære målet med signaturen er å fastslå JWT-ens autentisitet og bekrefte at dataene ikke har blitt tuklet med. Med andre ord kan informasjonen i tokenet verifiseres og stoles på, nettopp fordi tokenet er digitalt signert.

Det er viktig å forstå at selv om en signatur sikrer dataintegritet, hindrer den ikke andre i å se innholdet i tokenet. Derfor bør sensitiv informasjon som brukerpassord aldri overføres i en JWT; alt i overskriften og nyttelasten kan og bør være trygt for offentlig "forbruk".

Som nevnt tidligere signeres JWT-er utstedt av Idura Verify ved hjelp av RS256. RSA, som er en asymmetrisk algoritme, benytter par av kryptografisk koblede nøkler: én offentlig og én privat. Idura Verify har den private nøkkelen for signaturgenerering, mens applikasjonen som bruker JWT-er, kan hente en tilsvarende offentlig nøkkel fra metadataendepunktet og bruke den til å validere signaturen.

Offentlige nøkler er tilgjengelige på jwks_uri fra OpenID Connect Discovery-sluttpunktet. JWKS står for JWK Set, og representerer et sett med JSON-nettnøkler. For vårt eksempel-token er jwks_uri: https://demos-test.idura.broker/.well-known/jwks

Ettersom nøkler endres (nøkkelrotasjon), anbefales det å bruke endepunktet for dynamisk nøkkelhenting.

Når nøkler er inkludert i JWT-overskriften, er det dessuten viktig å kontrollere at de tilhører den forventede utstederen. Stol kun på tokens fra utstedere som er forhåndsregistrert i applikasjonen din.

Når bør du validere en JWT?

Du må alltid validere en innkommende JWT. Dette er den beste fremgangsmåten selv om du opererer i et internt nettverk der autorisasjonsserveren, klienten og ressursserveren ikke er koblet til Internett.

For OpenID Connect-flyter håndteres prosessen med å opprette og kode et JWT-token av OpenID Provider, mens valideringen må gjøres på serversiden av klientapplikasjonen. Du kan eventuelt også utføre validering på klientsiden: Det erstatter ikke de obligatoriske kontrollene i backend, men kan fungere som et hint, og potensielt en måte å redusere serverbelastningen på ved å ikke sende ugyldige JWT-er fra frontend til backend.

I prosjekter som baserer seg på JWT-basert autentisering, administreres tokenvalidering vanligvis av et dedikert bibliotek eller mellomvare, som vi skal illustrere nå.

JWT-validering trinn for trinn

I denne delen går vi gjennom JWT-valideringsprosessen, nok en gang med Idura Verify-utstedt ID-token som eksempel. Selv om enkelte detaljer, for eksempel hvor JWT-nøklene skal skaffes, er spesifikke for vårt tilfelle, gjelder den overordnede kombinasjonen av trinn for alle signerte JWT-er.

Her er de viktigste trinnene for å utføre JWT-validering:

• Hent og analyser JSON-nettnøkkelsettet (JWK-er)
• Dekode tokenet
• Verifisere påstandene
• Verifiser signaturen

Rekkefølgen disse trinnene utføres i, kan variere. For eksempel kan den rå JWT-en dekodes og analyseres først for å trekke ut `iss`-kravet, noe som gjør det mulig å avvise tokens fra utstedere som ikke er til å stole på, på et tidlig tidspunkt. På samme måte vil rekkefølgen for verifisering av krav og signatur avhenge av det valgte biblioteket. Det implementerende biblioteket kan selv bestemme rekkefølgen på disse trinnene, forutsatt at det oppfyller alle trinnene.

Hente JSON-nettnøkler

Hent JSON Web Key Set (JWKSet / JWKs) fra OIDC-discovery-endepunktet for domenet ditt hos Idura. OIDC-endepunktet inneholder metadata om tokenutstederen din. Du trenger jwks_uri som gir deg tilgang til JWK-er. Ideelt sett bør applikasjonen din sjekke og bufre disse nøklene med jevne mellomrom.

Dekod tokenet

Som nevnt er tokenene Base64URL-kodet, noe som betyr at du må dekode tokenet før du validerer det.

Verifiser krav

Verifiser følgende påstander i JWT-headeren:

• alg
  Den beste fremgangsmåten er å alltid sjekke verdien av alg-kravet mot en positivliste over algoritmer som systemet ditt godtar. Dette bidrar til å forhindre potensielle angrep der noen manipulerer tokenet for å få deg til å bruke en annen, sannsynligvis mindre sikker algoritme for signaturverifisering. Det finnes også en kjent angrepsvektor som utnytter "none"-verdien i alg-kravet.
  
  
  
• kid
  Påstander som peker mot offentlige nøkler, krever også spesiell oppmerksomhet. Hvis disse kravene er forfalsket, kan de lede tjenesten din til forfalskede verifiseringsnøkler og lure den til å godta ondsinnede tokens. Dobbeltsjekk at nøklene (eller eventuelle URL-adresser) i toppteksten samsvarer med utstederen av tokenet (utstedelsespåstanden ) eller har de verdiene du forventer.

Verifiser følgende påstander i JWT Payload:

• iss(utsteder)
  Utstederkravet skal samsvare med identifikatoren til OpenID-leverandøren din. Med OpenID Connect må utstederen representeres som en URL ved hjelp av HTTPS-skjemaet. I vårt scenario er utstederen for eksempel domenet vårt hos Idura: https://demos-test.idura.broker

Vi anbefaler at du kryssrefererer kravet med en godkjent liste over pålitelige utstedere, og at du alltid validerer at de kryptografiske nøklene som brukes til å signere tokenet, faktisk tilhører utstederen. Generelt sett er det viktig å bekrefte at tokenet stammer fra den forventede utstederen når du arbeider med JWT-er. Dette er spesielt viktig hvis applikasjonen din henter JWKS dynamisk.

• aud(publikum)
  Kontrolleralltid aud-kravet og bekreftat tokenet ble utstedt til et publikum som inkluderer applikasjonen din. Du bør avvise alle forespørsler som inneholder et token som er beregnet på forskjellige målgrupper.
  
  Et ID-token vil alltid inneholde klient-ID-en i aud-kravet. I vårt scenario vil aud-kravet være klient-ID-en til Idura Verify-applikasjonen vår.
  
  
  
• Tidsbaserte påstander
  Påstanden iat (issued at time) angir når ID-tokenet ble utstedt, uttrykti Unix-tid. Du kan bruke dette kravet til å avvise tokens som du anser som for gamle til å brukes av applikasjonen din.

Påstanden exp (expiry time) angir når dette tokenet utløper, uttrykt i Unix-tid. Du bør forsikre deg om at denne tiden ikke allerede har passert.

nbf-kravet ("not-before"-tid): Tokenet skal avvises hvis det nåværende tidspunktet er før tidspunktet i nbf-kravet.

En vanlig fallgruve er at klientapplikasjoner ikke tar høyde for en eller annen form for tidsforskyvning når de validerer disse påstandene. Forskjeller mellom tidsservere vil da føre til at tokens blir ugyldige. Vanligvis anbefales en verdi på 5 minutter for klokkeforskyvning.

Verifiser signaturen

For å oppsummere: Med RS256, som i vårt tilfelle, signeres JWT-er med en privat nøkkel når de genereres, og valideres med en offentlig nøkkel når de mottas. Validering er avgjørende for å sikre at tokenene ikke har blitt endret under transport.

Du verifiserer tokenets signatur ved å matche nøkkelen som brukes til å signere det, med en av nøklene du har hentet fra JWKs-sluttpunktet. Hver nøkkel identifiseres av et kid-attributt, som tilsvarer kid-kravet i tokenhodet.

Hvis kid-kravet ikke stemmer overens, og du bruker en eller annen form for hurtigbufring for JWKSets, er det mulig at signeringsnøklene kan ha blitt endret (nøkkelrullering). Hent data fra jwks_uri-endepunktet i OIDC-metadataene, og sjekk nøklene på nytt(du bør utføre denne nye hentingen nøyaktig én gang for å unngå uendelige sløyfer i tokenvalideringslogikken).

Implementering av validering

Det finnes flere måter å utføre JWT-validering på:

1. Eksisterende mellomvare

Du kan utnytte eksisterende mellomvare i webrammeverket ditt. ASP.NET har for eksempel en egen JWT-mellomvare som integreres sømløst med den overordnede autentiseringslogikken.

2. Tredjepartsbiblioteker

Vi anbefaler på det sterkeste at du velger et veletablert bibliotek for plattformen din for å utføre tokenvalidering. Du finner en omfattende liste over biblioteker for ulike språk på jwt.io. Når du skal velge, må du bekrefte at biblioteket støtter signeringsalgoritmen som brukes av JWT-ene dine, og sjekke hvilke krav det validerer. De fleste tredjepartsbiblioteker tilbyr en fleksibel verifiseringsmetode med argumenter som kan tilpasses, slik at du kan skreddersy verifiseringsprosessen til dine behov.

Du bør følge alle instruksjoner om hvordan du bruker det valgte biblioteket nøye, ettersom standardinnstillingene kan medføre potensielle sikkerhetsrisikoer.

3. manuell implementering (anbefales ikke):

Selv om RFC 7519 > 7.2 Validating a JWT beskriver viktige kontroller for validering av et token, frarådes manuell JWT-validering på det sterkeste på grunn av risikoen for at feil implementering kan føre til sikkerhetsproblemer.

Det anbefales på det sterkeste at du bruker mellomvare eller et av de eksisterende tredjepartsbibliotekene for å validere JWT-er. Nedenfor har vi inkludert kodeeksempler med eksempler på ulike språk.

Kodeeksempler

Python

Med PyJWT-biblioteket kan for eksempel et token verifiseres med decode-metoden, som sender tokenet videre og henter signeringsnøkkelen fra JWKS-sluttpunktet. PyJWKClient håndterer automatisk nøkkeloppløsningen basert på kid som finnes i JWT-overskriften.

import jwt
from jwt import PyJWKClient

token = "your_jwt_token"
url = "https://demos-test.idura.broker/.well-known/jwks"
optional_custom_headers = {"User-agent": "custom-user-agent"}

# Initialize PyJWKClient and fetch the signing key from JWKS
jwks_client = PyJWKClient(url, headers=optional_custom_headers)
signing_key = jwks_client.get_signing_key_from_jwt(token)

# Decode the token using the retrieved signing key
data = jwt.decode(
    token,
    signing_key.key,
    algorithms=["RS256"],
    audience="your_audience"
)
print(data)

NodeJS

Med jose-biblioteket bruker du funksjonen jwtVerify. For å få tak i de offentlige nøklene for verifisering kan du hente JSON Web Key Set fra et JWKS-sluttpunkt med createRemoteJWKSet . Kodeeksemplet nedenfor inkluderer også valgfrie parametere, for eksempel algoritme og spesifikke krav.

const jose = require('jose');
const token = 'your_jwt_token';
const JWKS = jose.createRemoteJWKSet(new URL('https://demos-test.idura.broker/.well-known/jwks'));

async function verifyToken() {
  try {
    const decodedToken = await jose.jwtVerify(token, JWKS, {
      algorithms: ['RS256'],
      issuer: 'https://demos-test.idura.broker',
      audience: 'your_audience',
    });
    console.log('Token is valid:', decodedToken);
  } catch (error) {
    console.error('Error verifying token:', error);
  }
}

verifyToken();

C#

Med Microsoft.IdentityModel.JsonWebTokens-biblioteket i C# kan du bruke JwtSecurityTokenHandler-klassen og bruke ValidateToken-metoden. Kodeeksemplet nedenfor inkluderer en asynkron GetJsonWebKeySetAsync-metode, som bruker HttpClient til å hente JSON Web Key Set fra et spesifisert endepunkt. TokenValidationParameters inkluderer innstillinger for validering av utsteder(ValidIssuer) og målgruppe(ValidAudience).

using System;
using System.IdentityModel.Tokens.Jwt;
using Microsoft.IdentityModel.Tokens;
using System.Net.Http;
using System.Threading.Tasks;

class Program
{
    static async Task Main()
    {
        var token = "your_jwt_token";
        var jwksEndpoint = "https://demos-test.idura.broker/.well-known/jwks.json";

        var jsonWebKeySet = await GetJsonWebKeySetAsync(jwksEndpoint);

        var handler = new JwtSecurityTokenHandler();
        var validationParameters = new TokenValidationParameters
        {
            ValidateIssuerSigningKey = true,
            IssuerSigningKeyResolver = (s, securityToken, identifier, parameters) => jsonWebKeySet.FindKey(identifier),
            ValidIssuer = "https://demos-test.idura.broker",
            ValidAudience = "your_audience"
        };

        try
        {
            var claimsPrincipal = handler.ValidateToken(token, validationParameters, out _);
            Console.WriteLine("Token is valid.");
        }
        catch (SecurityTokenException)
        {
            Console.WriteLine("Invalid token.");
        }
    }

    static async Task<JsonWebKeySet> GetJsonWebKeySetAsync(string jwksEndpoint)
    {
        using (var httpClient = new HttpClient())
        {
            var json = await httpClient.GetStringAsync(jwksEndpoint);
            return new JsonWebKeySet(json);
        }
    }
}

Oppsummering

Sikkerheten til JWT-er avhenger i stor grad av hvordan tokens brukes og valideres.

Det er viktig å understreke at JWT ikke er en protokoll, men kun et meldingsformat. RFC-en fungerer som en veiledning for strukturering av meldinger og inkorporering av sikkerhetslag for å beskytte meldingens integritet. Det er opp til den som implementerer å følge beste praksis når man arbeider med JWT-er. Derfor er det avgjørende å bruke et pålitelig verktøy eller bibliotek for å kode og dekode tokens og kontrollere gyldigheten.