Wikiternative
The Alternative Source

Post info:

JSON Web Token

JSON Web Token is een op JSON gebaseerde open standaard ( RFC 7519 ) voor het maken van toegangstokens die een aantal claims claimen. Een server kan bijvoorbeeld een token genereren met de claim ‘ingelogd als admin’ en dat aan een client te geven. De client kan dat token vervolgens gebruiken om te bewijzen dat het is aangemeld als beheerder. De tokens worden ondertekend door de sleutel van de server, zodat zowel de client als de server kunnen verifiëren dat het token legitiem is. De tokens zijn ontworpen om compact, URL- veilig en bruikbaar te zijn, met name in de context van eenmalige aanmelding voor eenmalige webbrowser. JWT-claims kunnen doorgaans worden gebruikt om de identiteit van geverifieerde gebruikers door te geven tussen een identiteitsprovider en een serviceprovider, of elk ander type claims zoals vereist door bedrijfsprocessen. De tokens kunnen ook worden geverifieerd en gecodeerd.

JWT vertrouwt op andere JSON-normen: JWS ( JSON Web Signature ) RFC 7515 en JWE (JSON Web Encryption) RFC 7516.

Inhoud

  • 1 Structuur
  • 2 Gebruik
  • 3 standaardvelden
  • 4 Implementaties
  • 5 Referenties
  • 6 Externe links

Structuur

JWT’s bestaan ​​over het algemeen uit drie delen: een header, een payload en een handtekening. De header identificeert welk algoritme wordt gebruikt om de handtekening te genereren en ziet er ongeveer zo uit:

 header = '{"alg": "HS256", "typ": "JWT"}'

HS256 geeft aan dat dit token is ondertekend met behulp van HMAC-SHA256.

De payload bevat de claims die moeten worden gedaan:

 payload = '{"loggedInAs": "admin", "iat": 1422779638}'

Zoals gesuggereerd in de JWT-specificatie, is een tijdstempel met de naam iat ( uitgegeven bij ) geïnstalleerd.

De handtekening wordt berekend door base64url te coderen voor de header en de payload en ze samen te voegen met een punt als scheidingsteken:

 key = 'secretkey'
 unsignedToken = encodeBase64Url (header) + '.'  + encodeBase64Url (payload)
 handtekening = HMAC-SHA256 (sleutel, unsignedToken) 

Alles bij elkaar is de handtekening gecodeerd met base64url. De drie afzonderlijke delen worden aaneengeschakeld met behulp van punten:

 token = encodeBase64Url (header) + '.'  + encodeBase64Url (payload) + '.'  + encodeBase64Url (handtekening) # token is nu: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI 

De uitvoer bestaat uit drie Base64url-reeksen gescheiden door punten die eenvoudig kunnen worden doorgegeven in HTML- en HTTP- omgevingen, terwijl ze compacter zijn in vergelijking met op XML gebaseerde standaarden zoals SAML . Typische cryptografische algoritmen die worden gebruikt, zijn HMAC met SHA-256 (HS256) en RSA-handtekening met SHA-256 (RS256). JWA (JSON Web Algorithms) RFC 7518 introduceert nog veel meer voor zowel verificatie als versleuteling. [9]

Gebruik

Bij authenticatie, wanneer de gebruiker zich met succes aanmeldt met zijn inloggegevens, wordt een JSON Web Token teruggestuurd en moet deze lokaal worden opgeslagen (meestal in lokale of sessieopslag , maar er kunnen ook cookies worden gebruikt), in plaats van de traditionele aanpak om een ​​sessie te maken in de server en een cookie retourneren.

Wanneer de gebruiker toegang wil krijgen tot een beschermde route of bron, moet de user-agent de JWT verzenden, meestal in de Authorization volgens het Bearer . De inhoud van de koptekst ziet er als volgt uit:

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

Dit is een stateloos authenticatiemechanisme omdat de gebruikersstatus nooit wordt opgeslagen in het servergeheugen. De beschermde routes van de server zullen controleren of er een geldige JWT is in de autorisatiekop en als deze aanwezig is, krijgt de gebruiker toegang tot beschermde bronnen. Aangezien JWT’s op zichzelf staan, is alle benodigde informatie aanwezig, waardoor de noodzaak om de database meerdere keren te ondervragen kleiner wordt.

Standaard velden

De concepten voor internet definiëren de volgende standaardvelden (“claims”) die binnen een JWT-claimset kunnen worden gebruikt:

  • Emittent ( iss ) – identificeert hoofdsom die de JWT heeft uitgegeven;
  • Onderwerp ( sub ) – identificeert het onderwerp van de JWT;
  • Publiek ( aud ) – De “aud” (doelgroep) claim identificeert de ontvangers waarvoor de JWT is bedoeld. Elke opdrachtgever die van plan is om de JWT te verwerken, moet zich identificeren met een waarde in de publieksclaim. Als de principal die de claim verwerkt zich niet identificeert met een waarde in de aud claim wanneer deze claim aanwezig is, moet de JWT worden afgewezen.
  • Vervaltijd ( exp ) – De claim “exp” (vervaltijd) geeft de vervaltijd aan waarop de JWT niet mag worden geaccepteerd voor verwerking. De waarde moet de indeling NumericDate [10] [11] hebben.
  • Not before ( nbf ) – Op dezelfde manier identificeert de not-before time claim het tijdstip waarop de JWT geaccepteerd zal worden voor verwerking.
  • Uitgegeven te ( iat ) – De “iat” (uitgegeven bij) claim identificeert het tijdstip waarop de JWT werd uitgegeven.
  • JWT ID ( jti ) – hoofdlettergevoelige unieke identifier van het token, zelfs bij verschillende emittenten.

De volgende velden kunnen worden gebruikt in verificatiekoppen:

  • Token type ( typ ) – Indien aanwezig, wordt het aanbevolen om dit op JWT . [1]
  • Inhoudstype ( cty ) – Als geneste ondertekening of codering wordt gebruikt, is het aan te raden dit in te stellen op JWT , anders dit veld weg te laten. [1]
  • Message authentication code algorithm ( alg ) – De uitgever kan vrij een algoritme instellen om de handtekening op het token te verifiëren. Sommige ondersteunde algoritmen zijn echter onveilig. [5]
  • Alle andere headers geïntroduceerd door JWS en JWE [7] [8]

Implementaties

JWT-implementaties bestaan ​​voor Clojure, .NET, Go , Haskell, Python, Node.js, Java, JavaScript, Lua, Perl, PHP, Robijn, Roest, Scala, Erlang, Gemeenschappelijke Lisp en Elixir.