Waar zou ik secret key van een JWT moeten opslaan.

[Verwijderd]

Ik ben op dit moment bezig met het ontwerpen van een REST API en de beveiliging er van.

voor het authentiseren van een gebruiker wordt gebruik gemaakt van een LDAP server. Wanneer de gebruiker geauthentiseerd is, wordt er een JWT gegenereerd met HMAC beveiliging. Op het moment dat een JWT wordt gegenereerd, waar laat je de secret key aan de server side? Als een secret key wordt opgeslagen bij de gebruiker in een database, betekend dit dan niet dat server weet wat de status is van een gebruiker en daarbij niet meer RESTful is?

Iemand die hier een oplossing voor weet?

Groetjes,

Milkyway1995

[Janoz]

Je hebt geen secret key per gebruiker nodig. De secret key kan gewoon applicationscope zijn.

[Beyond]

Inderdaad, de secret gebruik je voor het maken van de jwt op applicatie of tenant niveau.

[Hydra]

Verwijderd schreef op dinsdag 19 september 2017 @ 10:10:
Als een secret key wordt opgeslagen bij de gebruiker in een database, betekend dit dan niet dat server weet wat de status is van een gebruiker en daarbij niet meer RESTful is?

Afgezien van dat je het antwoord al hebt; hoe kom je erbij dat een restful server geen data voor een user op mag slaan in bijv. een database? Hoe denk je ooit ergens een back-end voor te bouwen? Je wil geen sessie-state bijhouden maar da's niet perse "REST" eigenschap maar eentje die draait om schaalbaarheid.

[Gomez12]

Verwijderd schreef op dinsdag 19 september 2017 @ 10:10:
Als een secret key wordt opgeslagen bij de gebruiker in een database, betekend dit dan niet dat server weet wat de status is van een gebruiker en daarbij niet meer RESTful is?

Je definities beter stellen dat is de oplossing...

Bij RESTful is het irrelevant of de server weet wat de status is van een gebruiker (sterker nog, dit zal in praktisch de meeste gevallen verplicht zijn, net zoals de server ook de status moet weten van bijv artikelen etc)

RESTful gaat er meer over dat je alle statussen die je nodig hebt binnen je request afhandelt en niet afhankelijk bent van andere requests.
Maar wat je binnen je request zelf doet dat is helemaal aan jou.

[Tubby]

Het stateless gebeuren van REST is een leuk principe totdat de content die geserveerd wordt gefilterd of enigzins afhankelijk is van de gebruiker die het opvraagd; dan ontkom je niet aan enige vorm van state.

Most namely de authentication state, een deel hiervan kun je meegeven in je JWT Token, de username en z'n rollen. Maar afhankelijk van hoeveel dat is kan dat wel impact hebben op je performance aangezien dit token wel bij elk request mee komt.

Serverside als je een standaard jwt lib gebruikt zal dit waarschijnlijk ergens in een cache blijven plakken maar het zal hoe-dan-ook met elk request meekomen. Dus vaak vul je je JWT token aan met eventuele extra authorisatie rollen e.d. en soms heb je ook requirements om die dicteren dat je moet checken of die gebruiker nog wel actief is e.d.

Meestal voldoet het verder om één secret te hebben op applicatie-scope, let wel op dat als je meerdere servers hebt draaien dat die met hetzelfde secret moeten werken

[ Voor 9% gewijzigd door Tubby op 22-09-2017 15:44 ]