Nieuw: download het JWT handboek gratis en leer JWTs in de diepte!
Wat is JSON Web Token?
JSON Web Token (JWT) is een open standaard (RFC 7519) die een compacte en op zichzelf staande manier definieert voor het veilig verzenden van informatie tussen partijen als een JSON-object. Deze informatie kan worden geverifieerd en vertrouwd omdat deze digitaal is ondertekend. JWTs kan worden ondertekend met behulp van een geheim (met het HMAC algoritme) of een publiek/private sleutelpaar met behulp van RSA of ECDSA.,
hoewel JWTs kan worden versleuteld om ook geheimhouding tussen partijen te bieden, zullen we ons richten op ondertekende tokens. Ondertekende tokens kunnen de integriteit van de claims in het controleren, terwijl versleutelde tokens verbergen die claims van andere partijen. Wanneer tokens worden ondertekend met behulp van publiek-private sleutelparen, certificeert de handtekening ook dat alleen de partij die de persoonlijke sleutel heeft, degene is die de sleutel heeft ondertekend.
Wanneer moet u JSON-Webtokens gebruiken?
Hier zijn enkele scenario ‘ s waar JSON Web Tokens nuttig zijn:
-
autorisatie: dit is het meest voorkomende scenario voor het gebruik van JWT., Zodra de gebruiker is ingelogd, zal elke volgende aanvraag de JWT bevatten, waardoor de gebruiker toegang heeft tot routes, services en bronnen die zijn toegestaan met dat token. Single Sign On is een functie die veel gebruik maakt van JWT tegenwoordig, vanwege de kleine overhead en de mogelijkheid om gemakkelijk te worden gebruikt in verschillende domeinen.
-
informatie-uitwisseling: JSON-Webtokens zijn een goede manier om informatie veilig tussen partijen door te geven. Omdat JWTs kan worden ondertekend-bijvoorbeeld met behulp van publieke / private sleutelparen-kunt u er zeker van zijn dat de afzenders zijn wie ze zeggen dat ze zijn., Bovendien, als de handtekening wordt berekend met behulp van de header en de payload, kunt u ook controleren of de inhoud niet is geknoeid met.
Wat is de JSON Web Token structuur?
in zijn compacte vorm bestaan JSON-Webtokens uit drie delen gescheiden door punten (.
), die zijn:
- Header
- Payload
- Signature
daarom ziet een JWT er meestal als volgt uit.
xxxxx.yyyyy.zzzzz
laten we de verschillende delen opsplitsen.,
Header
de header bestaat doorgaans uit twee delen: het type token, dat JWT is, en het gebruikte ondertekeningsalgoritme, zoals HMAC SHA256 of RSA.
bijvoorbeeld:
{ "alg": "HS256", "typ": "JWT"}
dan is dit JSON base64url gecodeerd om het eerste deel van de JWT te vormen.
Payload
het tweede deel van het token is de payload, die de claims bevat. Claims zijn verklaringen over een entiteit (meestal de gebruiker) en aanvullende gegevens.Er zijn drie soorten claims: geregistreerde, publieke en private claims.,
-
geregistreerde claims: dit zijn een set van vooraf gedefinieerde claims die niet verplicht maar aanbevolen zijn om een set nuttige, interoperabele claims te leveren. Sommige zijn: ISS (uitgever), exp (vervaldatum), sub (onderwerp), AUD (publiek), en anderen.
merk op dat de claimnamen slechts drie karakters zijn zolang JWT bedoeld is om compact te zijn.
-
publieke claims: deze kunnen naar believen worden gedefinieerd door degenen die JWTs gebruiken., Maar om botsingen te voorkomen moeten ze worden gedefinieerd in het IANA JSON Web Token Register of worden gedefinieerd als een URI die een botsingsbestendige naamruimte bevat.
-
Privéclaims: dit zijn de aangepaste claims die worden gemaakt om informatie te delen tussen partijen die ermee instemmen ze te gebruiken en die geen geregistreerde of publieke claims zijn.
een voorbeeld van payload zou kunnen zijn:
{ "sub": "1234567890", "name": "John Doe", "admin": true}
de payload wordt dan base64url gecodeerd om het tweede deel van het JSON Web Token te vormen.,
merk op dat Voor ondertekende tokens deze informatie, hoewel beschermd tegen manipulatie, leesbaar is voor iedereen. Zet geen geheime informatie in de payload of header elementen van een JWT tenzij deze versleuteld is.
Signature
om het handtekeninggedeelte te maken moet u de gecodeerde header, de gecodeerde payload, een geheim, het algoritme dat in de header is gespecificeerd, en ondertekenen.,
als u bijvoorbeeld het algoritme HMAC SHA256 wilt gebruiken, zal de ondertekening op de volgende manier worden aangemaakt:
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
De ondertekening wordt gebruikt om te controleren of het bericht onderweg niet is gewijzigd, en, in het geval van tokens ondertekend met een privésleutel, kan het ook controleren of de afzender van de JWT is wie het zegt dat het is.
alles samenvoegen
de uitvoer bestaat uit drie Base64-URL-strings gescheiden door puntjes die gemakkelijk kunnen worden doorgegeven in HTML-en HTTP-omgevingen, terwijl ze compacter zijn in vergelijking met XML-gebaseerde standaarden zoals SAML.,
het volgende toont een JWT die de vorige header en payload gecodeerd heeft, en het is ondertekend met een geheim.
Als u met JWT wilt spelen en deze concepten in de praktijk wilt brengen, kunt u jwt.io Debugger om JWTs te decoderen, te verifiëren en te genereren.
Hoe werken JSON-Webtokens?
Bij authenticatie wordt een JSON Webtoken geretourneerd als de gebruiker met succes inlogt met zijn referenties. Aangezien tokens zijn geloofsbrieven, grote zorg moet worden genomen om beveiligingsproblemen te voorkomen., In het algemeen, moet u tokens niet langer dan vereist.
u moet ook geen gevoelige sessiegegevens opslaan in browseropslag vanwege een gebrek aan beveiliging.
wanneer de gebruiker toegang wil tot een beveiligde route of bron, moet de user agent de JWT verzenden, meestal in de autorisatie header met behulp van het Toonderschema. De inhoud van de header moet er als volgt uitzien:
Authorization: Bearer <token>
Dit kan in bepaalde gevallen een staatloos autorisatiemechanisme zijn., De beveiligde routes van de server zullen controleren op een geldige JWT in de Authorization
header, en als deze aanwezig is, zal de gebruiker toegang krijgen tot beveiligde bronnen. Als de JWT de nodige gegevens bevat, kan de noodzaak om de database te bevragen voor bepaalde bewerkingen worden verminderd, hoewel dit niet altijd het geval is.
als het token wordt verzonden in de Authorization
header, zal Cross-Origin Resource Sharing (CORS) geen probleem zijn omdat het geen cookies gebruikt.,
het volgende diagram laat zien hoe een JWT wordt verkregen en gebruikt om toegang te krijgen tot API ‘ s of bronnen:
- De toepassing of client vraagt autorisatie aan de autorisatieserver. Dit gebeurt via een van de verschillende autorisatiestromen. Een typische OpenID Connect-compatibele webtoepassing zal bijvoorbeeld het
/oauth/authorize
eindpunt doorlopen met behulp van de stroom autorisatiecode. - wanneer de autorisatie wordt verleend, retourneert de autorisatieserver een toegangstoken naar de toepassing.,
- de toepassing gebruikt het toegangstoken om toegang te krijgen tot een beschermde bron (zoals een API).
merk op dat met ondertekende tokens alle informatie in het token wordt blootgesteld aan gebruikers of andere partijen, ook al kunnen zij het niet wijzigen. Dit betekent dat je geen geheime informatie in de token moet zetten.
waarom zouden we JSON-Webtokens moeten gebruiken?
laten we het hebben over de voordelen van JSON Web Tokens (JWT) in vergelijking met Simple Web Tokens (SWT) en Security Assertion Markup Language Tokens (SAML).,
omdat JSON minder uitgebreid is dan XML, is de grootte ook kleiner wanneer het gecodeerd is, waardoor JWT compacter is dan SAML. Dit maakt JWT een goede keuze om te worden doorgegeven in HTML en HTTP-omgevingen.
veiligheidstechnisch kan SWT alleen symmetrisch worden ondertekend door een gedeeld geheim met behulp van het HMAC-algoritme. JWT en SAML tokens kunnen echter een publiek / privé sleutelpaar gebruiken in de vorm van een X. 509 certificaat voor ondertekening. Het ondertekenen van XML met XML Digital Signature zonder obscure beveiligingslekken te introduceren is erg moeilijk in vergelijking met de eenvoud van het ondertekenen van JSON.,
JSON parsers zijn gebruikelijk in de meeste programmeertalen omdat ze direct aan objecten toewijzen. Omgekeerd, XML heeft geen natuurlijke document-to-object toewijzing. Dit maakt het makkelijker om te werken met JWT dan SAML beweringen.
wat het gebruik betreft, wordt JWT gebruikt op internetschaal. Dit benadrukt het gemak van client-side verwerking van de JSON Web token op meerdere platforms, vooral mobiele.,
vergelijking van de lengte van een gecodeerde JWT en een gecodeerde SAML
Als u meer wilt lezen over JSON-Webtokens en ze zelfs wilt gebruiken om authenticatie uit te voeren in uw eigen toepassingen, blader dan naar de landing page van JSON-Webtoken op Auth0.
Leave a Reply