JWT nieuwe standaard?

[Jiggle]

Voor mijn werk moet ik een website maken die gegevens ophaalt via een WebAPI. Bij de aanroep moeten we een JWT-token meegeven. Dat hebben we eerder nog nooit gedaan.
Wij werken met in-house ontwikkelde software, dus we hebben nu 2 opties:
- ofwel we bouwen dat JWT-token custom made voor deze klant
- ofwel we gaan deze optie integreren in onze software, zodat die generiek toepasbaar is.

Dat laatste is wenselijk als we in de toekomst meerdere verzoeken kunnen verwachten, oftewel dat JWT-tokens een veelgebruikte standaard gaan worden. Ik kan daar eigenlijk niet zoveel over vinden op internet, wel dat de techniek redelijk nieuw is. Iemand die hier meer info over kan geven? Of weet te vinden op internet?

[DonJunior]

Toevallig van de week nog opgezet icm ASP .NET Core
Moet zeggen dat het eigenlijk vrij simpel is.

Loop deze eens goed door..
https://auth0.com/blog/se...2-applications-with-jwts/

Als je het concept snapt is het erg makkelijk.

[Jiggle]

Dank voor de tip! Die geef ik door aan de ontwikkelaars hier.
Antwoord dat ik echter vooral moet hebben is of dit nu een populaire of populairder wordende standaard is. Scheelt nogal wat bouwtijd als we het token even alleen voor deze klant inrichten of dat we een generieke opzet moeten gaan maken.

[DonJunior]

Als je dit nu alleen voor de klant opzet. Kun je het later altijd nog ombouwen tot een generiek project.
Generiek klinkt altijd leuk maar het kost altijd meer werk dan nodig omdat je altijd tegen uitzondering aan loopt.
Dus voor nu, gewoon voor het project van de klant opzetten. Mocht je er later weer tegenaan lopen (voor een ander project) kun je het altijd nog generiek op gaan zetten en gebruiken.

[DJMaze]

DonJunior schreef op donderdag 25 januari 2018 @ 16:17:
Generiek klinkt altijd leuk maar het kost altijd meer werk dan nodig omdat je altijd tegen uitzondering aan loopt.

JWT uitzonderingen?
Als het een uitzondering is, is het geen JWT.
Maak dus gewoon 1 class die je kan hergebruiken.

[FastFox91]

Elke taal heeft al wel een jwt library, dus dat kan je prima gebruiken. Hoe je jwt gebruikt, dat kan op allemaal verschillende manieren en is niet vastgelegd in een "jwt standaard", zoals oauth dat wel probeert.

Ik ben het eens met het idee van DonJunior. Probeer het uit voor deze klant en trek daarna je conclusies.

[ Voor 20% gewijzigd door FastFox91 op 25-01-2018 16:30 ]

[DonJunior]

DJMaze schreef op donderdag 25 januari 2018 @ 16:28:
[...]

JWT uitzonderingen?
Als het een uitzondering is, is het geen JWT.
Maak dus gewoon 1 class die je kan hergebruiken.

Authenticatie implementatie kan alsnog per klant verschillend zijn. Dat kun je nu niet voorzien. Dus maak je nu de moeite om het generiek op te zetten en loop je bij het volgende project er weer tegenaan dat je het toch moet wijzigen omdat het daar net even anders gaat.

[DJMaze]

@DonJunior wie heeft het hier over authenticatie?
JWT is helemaal geen authenticatie, en kan voor vanalles gebruikt worden, precies zoals FastFox91 zegt.
JWT is namelijk een verificatie signature.

OpenID Connect (authenticatie) gebruikt JWT en JWK voor de verificatie van een bericht.

[ Voor 18% gewijzigd door DJMaze op 25-01-2018 16:34 ]

[DonJunior]

DJMaze schreef op donderdag 25 januari 2018 @ 16:33:
@DonJunior wie heeft het hier over authenticatie?
JWT is helemaal geen authenticatie, en kan voor vanalles gebruikt worden, precies zoals FastFox91 zegt.
JWT is namelijk een verificatie signature.

Om een token uit te delen moet je toch verifiëren wie degene is die de token aanvraagt? Of?

[CH4OS]

DonJunior schreef op donderdag 25 januari 2018 @ 16:35:
Om een token uit te delen moet je toch verifiëren wie degene is die de token aanvraagt? Of?

JWT is geen authenticator.

[Groentjuh]

Een JWT bevat een aantal claims. Door de signature te valideren, valideer je dat er niet gerommeld is met die claims en deze dus kloppen.

Dat JWT veelal gebruikt wordt met bijvoorbeeld een uid/user_id claim erin is iets wat niet gedicteerd is door JWT.

[DonJunior]

CH4OS schreef op donderdag 25 januari 2018 @ 16:37:
[...]
JWT is geen authenticator.

Dat begrijp ik. Maar ik zal toch moeten weten aan wie (of wat) ik de token overhandig? Dus moet diegene die een token wenst (om vervolg request te kunnen doen) zich moeten identificeren niet?

[DJMaze]

@DonJunior je moet het zo zien:

Ik stuur jou een brief via PostNL (JWT).
Hierin zeg ik dat ik DJMaze ben (identificatie / token / payload).
Dat weet jij niet zeker totdat je mijn handtekening (signature JWS) op die brief ziet.
Klopt die handtekening niet, dan weet je dat de brief niet van mij afkomstig is.

[ Voor 3% gewijzigd door DJMaze op 26-01-2018 10:04 ]

[DonJunior]

Zoals ik het nu heb opgezet:
1: Ik stuur een request naar de Token server voor een Token. Deze aanvraag bevat mijn 'credentials'
2: De Token server bevestigd dat ik ben wie ik ben en retourneert mij een Token.
3: Ik kan nu met de Token requests gaan doen richting de API, totdat mijn token verloopt.

Door het token hoef ik niet voor elke request in te loggen op de API.. maar weet de API wel dat ik DonJunior ben.

[DJMaze]

Juist, maar dat is niet JWT. Dat is bijvoorbeeld OAuth.

En als ik je token heb (MITM), kan ik namelijk ook requests doen.
De server kan alleen weten of de request daadwerkelijk van jou is als ook de signature klopt.
De signature kan op verschillende manieren worden gemaakt (Hash, HMAC symetrisch = JWS, SSL asymetrisch = JWE).

[Jiggle]

Dank voor alle bijdragen, ik denk dat dat zeer bruikbaar is voor ons.
Maar toch nog ff de originele vraag tussendoor:
Is nu de verwachting dat over een tijdje JWT-tokens gemeengoed zijn geworden en elke API een aanroep incl JWT-token zal verwachten? Of zal het gewoon een van de vele mogelijkheden blijven om een API te beveiligen?

[Cartman!]

Wij gaan alweer over naar PAST: https://github.com/paragonie/past

Komt grotendeels op t zelfde neer maar PAST voorkomt voornamelijk dat je een library gebruikt waar je als gebruiker het algoritme kan overschrijven waardoor er geen goede controle is.

[Caelorum]

Jiggle schreef op donderdag 25 januari 2018 @ 17:42:
[...] Is nu de verwachting dat over een tijdje JWT-tokens gemeengoed zijn geworden en elke API een aanroep incl JWT-token zal verwachten? ]...]

Dat is het nu al een beetje bij nieuwe APIs.

Of zal het gewoon een van de vele mogelijkheden blijven om een API te beveiligen?

Zoals altijd blijven oude standaarden gewoon in gebruik totdat het echt onveilig is om te gebruiken (en zelfs dan). Dus natuurlijk blijft het 1 van de vele mogelijkheden.

Ik heb in de afgelopen maanden gewerkt aan een implementatie die reference tokens gebruikt i.p.v. JWT, maar ja. Je moet gewoon kijken wat voor jullie voldoet en de documentatie fatsoenlijk maken. Als de documentatie goed is, dan zal iedere softwareontwikkelaar er wel wat mee moeten kunnen doen en dan maakt het dus niet uit of je een 'standaard' kiest (afgezien van dat je met een standaard ook van standaard libs gebruik kan maken en dus niet zelf fouten introduceert).

[Hydra]

Heb hier een tijdje geleden een blog post over geschreven. Mocht je naar aanleiding daarvan vragen hebben; shoot.

Het gebruik van API tokens is al een tijdje gemeengoed. Een nadeel daarvan is dat je aan de hand van dat token dan, zoals bij een sessie ID, de gegevens van de API gebruiker erbij moet zoeken. Het enige verschil is dus eigenlijk dat een JWT die informatie bij zich draagt; gesigned of encrypted, zodat ze tamper-proof zijn.

Het is gewoon een standaard die vaak toegepast wordt en als voordeel heeft dat het alle authorisatie state bij zich draagt. Het enige waar je even op moet letten is dat je goed checkt of het token dat je krijgt het algoritme gebruikt dat je verwacht. Een aantal libraries implementeren ook 'netjes' hey 'none' algoritme.

[P1nGu1n]

Op het werk ben ik ook met JWT bezig geweest, zowel JWS (signing) als JWE (encryption) - voor OpenID Connect om precies te zijn. Dit is de blog die mij hier met afstand de meeste info over heeft gegeven: JWT, JWS and JWE for Not So Dummies. Bevat alles rondom JWT: compleet en enorm in-depth.

Wat betreft je project: verwacht je dat je het mogelijk nodig gaat hebben, dan stop je de implementatie in het project van de klant, dan kan je het altijd eenvoudig verplaatsen. Verwacht je dat je het sowieso voor andere projecten nodig gaat hebben, dan kan je het net zo goed direct in je eigen software stoppen. Maar ik zou het persoonlijk sowieso generiek opzetten, in welke van de twee projecten het ook eindigt.

[ Voor 3% gewijzigd door P1nGu1n op 26-01-2018 11:25 ]

[Janoz]

Maar even terug naar het issue van de topicstarter. Hij gebruikt een api die JWT gebruikt. Voor de gebruiker van die api maakt dat natuurlijk helemaal geen kont uit.

Je doet je authenticatie en krijgt een dingetje terug. Vervolgens geef je een dingetje mee met elk request om aan te geven dat jij het bent. Of dat dingetje nu een session_id, JWT, of "?username=hoi&password=secret" is maakt natuurlijk helemaal niet uit.

Voor de topicstarter zijn maar 2 dingen belangrijk:
1 - Hoe kom ik aan het token. Dit is niet JWT specifiek maar waarschijnlijk wel gedocumenteerd.
2 - Kan mijn systeem een 'Authorization: Bearer xxx.yyy.zzz' header meesturen met het request.

[Cartman!]

Janoz schreef op vrijdag 26 januari 2018 @ 11:18:
Maar even terug naar het issue van de topicstarter. Hij gebruikt een api die JWT gebruikt. Voor de gebruiker van die api maakt dat natuurlijk helemaal geen kont uit.

Helemaal eens echter kan t best zijn dat er al iets in de payload zit wat je direct kunt gebruiken zonder dat je een extra call naar de API nodig hebt. Denk aan bijv. een id om tegen te valideren voor SSO of een username oid.

offtopic:
Overigens kun je een ID voor SSO alleen gebruiken als de secret daadwerkelijk bekend is bij jezelf zoals dat bijv met Facebook Signed Requests zo is, wat min of meer een voorloper is van JWT in zekere zin, geen idee of ze dat nog gebruiken.

[ Voor 19% gewijzigd door Cartman! op 26-01-2018 22:38 ]

[Verwijderd]

Maar je werkt met inhouse software, betreft web technologie wat met de "maanden" verandert en je verwacht van het web dat ze stil blijven zitten bij één enkele standaard?

Je moet je inhouse software zo maken dat het een levende standaard is en met het web mee kan evolueren. Het web gaat echt niet stil zitten hoor!!
Nu is het JWT en morgen is het weer iets anders. Je kan er beter voor zorgen dat je zorgt dat de inhouse software flexibel mee gaat groeien met de wereld van het web. Die wereld is verschrikkelijk veranderlijk.

[Xantios]

JWT Ga je in de praktijk denk ik voorlopig nog wel even zien

Tuurlijk, het is altijd beetje in de glazen bol kijken. maar het concept van "log in en krijg een token die gebruikt voor de komende requests" zie je al meer dan 10 jaar

dat JWT daar nu voor gebruikt wordt is mijn inziens voornamelijke een prettige standaardisatie.

[qless]

Wij gebruiken het nu zelf als "standaard" bij nieuwe projecten. Wij deden eerst "gewone" tokens, maar JWT heeft oa. het voordeel dat we zaken als rolen, userid e.d. gewoon kunnen meegeven. En omdat JWT gesigned is, kan de server het token ook vertrouwen, en hoeft dan voor bijvoorbeeld controle op rolen geen database calll te doen met user id, maar kan de rollen uit de jwt token gebruiken.

Nog een handige site voor JWT:
https://jwt.io/

[Janoz]

qless schreef op woensdag 31 januari 2018 @ 09:13:
Wij gebruiken het nu zelf als "standaard" bij nieuwe projecten. Wij deden eerst "gewone" tokens, maar JWT heeft oa. het voordeel dat we zaken als rolen, userid e.d. gewoon kunnen meegeven. En omdat JWT gesigned is, kan de server het token ook vertrouwen, en hoeft dan voor bijvoorbeeld controle op rolen geen database calll te doen met user id, maar kan de rollen uit de jwt token gebruiken.

Nog een handige site voor JWT:
https://jwt.io/

Hou er wel rekening mee dat je in dat geval dus niet heel makkelijk de rollen van een gebruiker aan kunt passen. Wanneer je een autorisatie verwijdert of toevoegt, geld dat pas waneer het token ververst wordt.