Relatie tussen user roles en OAuth2 scopes

[egonolieux]

Ik heb een REST API die ik moet beveiligen en ben me daarom aan het verdiepen in OAuth2 als mogelijke optie. Tot zo ver ik begrijp is het een framework voor gedelegeerde authorisatie. Dat wil zeggen dat een client (app) de resources van een user kan gebruiken door aan de user toestemming te vragen via het platform waar de gegevens zich bevinden. Hierbij kan de client (app) een aantal scopes/permissions opgeven, zodat de gebruiker weet welke gegevens de client (app) nodig heeft.

Binnen mijn backend hebben geregistreerde users één of meer roles die bepalen welke permissies ze hebben. Mijn verwarring is dat binnen OAuth2 de permissies (scopes) worden bepaald door de client (app) en niet door de gebruiker. Dat is logisch als je als je app gebruikt maakt van gegevens van de gebruiker bij een 3de partij (gedelegeerde authorisatie), maar niet als je de gegevens op je eigen REST API met de rechten van je eigen gebruikers via je eigen app wilt beheren.

Overal lijkt iedereen OAuth2 aan te raden om REST APIs te beveiligen, maar tot zo ver ik begrijp lijkt het helemaal niet gemaakt voor situaties waarbij je simpelweg je eigen gebruikers wilt laten aanmelden op je REST API? Momenteel lijkt het me het eenvoudigst een variatie op HTTP Basic Auth te gebruiken waarbij de gebruiker zijn credentials via Basic Auth omwisselt voor een access token. Deze access token is dan een een performante manier om aan Basic Auth te doen zonder de overhead van password hashing (bcrypt, argon, ...). Dit lijkt op de OAuth2 ROPC grant type, maar op deze manier kan ik in ieder geval mijn eigen roles gebruiken.

Wat mis ik hier?

[Carbon]

maar tot zo ver ik begrijp lijkt het helemaal niet gemaakt voor situaties waarbij je simpelweg je eigen gebruikers wilt laten aanmelden

Je constatering is correct, OAuth2 is niet bedoeld voor user authenticatie!
Dat gaat via OpenID, een kleine uitbreiding op OAuth2

Zie: YouTube: OAuth 2.0 and OpenID Connect (in plain English)

[ Voor 53% gewijzigd door Carbon op 06-07-2019 23:52 ]

[egonolieux]

De officiele manier voor identificatie is inderdaad via OpenID Connect, maar het kan evengoed ook via een "/user" API endpoint zoals velen dit doen. Maar dit is niet mijn punt.

Het probleem is dat mijn backend users heeft die bepaalde roles hebben. Ik begrijp niet goed hoe ik dit kan integreren met OAuth scopes. In OAuth worden de scopes door de app zelf aan de gebruiker voorgelegd voordat hij zich authenticeert, maar de app zelf heeft geen flauw idee welke roles de user heeft (omdat deze nog niet geauthenticeerd is). Het is dus perfect mogelijk dat de app scopes vraagt die de user niet bezit als roles.

Ik had misschien dat laatste deel van mijn vorige post moeten weglaten; dat was meer uit frustratie . In principe heb ik geen OAuth nodig en kan het ook simpelweg met een login per gebruiker, maar ik dacht dit als een gelegenheid te zien me eens in OAuth te verdiepen. Het moest er vroeg of laat toch van komen.

[ Voor 20% gewijzigd door egonolieux op 07-07-2019 07:31 ]

[Janoz]

Nee hoor. Met dat laatste punt heb je volledig gelijk. OAuth is inderdaad niet (primair) bedoeld om je rest service te beveiligen. OAuth is vooral een systeem om authenticatie te doen door een 3e partij die door aanbieder en afnemer vertrouwd wordt. Je Google account gebruiken om bij de epic gamestore of met je facebook account inloggen bij een webwinkel, maar bijvoorbeeld ook je DigiD gebruiken om bij je verzekering in te loggen.

Voor jouw toepassing is OAuth nodeloos ingewikkeld. Gebruik inderdaad gewoon een token die je opvraagt middels Basic (mits het via https gaat!) of digest authentication. Kijk voor het token dan gelijk even naar JWT. Dan kun je je REST service helemaal stateless houden en heb je aan de serverkant ook geen sessie meer nodig.

[whoami]

egonolieux schreef op zondag 7 juli 2019 @ 07:19:

Het probleem is dat mijn backend users heeft die bepaalde roles hebben. Ik begrijp niet goed hoe ik dit kan integreren met OAuth scopes. In OAuth worden de scopes door de app zelf aan de gebruiker voorgelegd voordat hij zich authenticeert, maar de app zelf heeft geen flauw idee welke roles de user heeft (omdat deze nog niet geauthenticeerd is). Het is dus perfect mogelijk dat de app scopes vraagt die de user niet bezit als roles.

Die roles hoef je imho niet te integreren met scopes.
Scopes gebruik je -imho- om bepaalde operaties van je API af te bakenen. Ik zie het zo: om bepaalde operaties op een API uit te mogen voeren, heb je scope X nodig. Voor andere operaties binnen die API heb je scope Y nodig.

Bij het aanmaken van je access-token kan je m.i. de role van een user (en evt nog andere zaken) toevoegen als claim aan je access token.

Janoz schreef op zondag 7 juli 2019 @ 10:51:

Voor jouw toepassing is OAuth nodeloos ingewikkeld. Gebruik inderdaad gewoon een token die je opvraagt middels Basic (mits het via https gaat!) of digest authentication. Kijk voor het token dan gelijk even naar JWT. Dan kun je je REST service helemaal stateless houden en heb je aan de serverkant ook geen sessie meer nodig.

Ga je in dat geval dan helemaal zelf je token gaan opbouwen ?
Ik heb momenteel een REST api in .NET ontwikkelt, waarbij ik zelf ook controle heb over de users. Ik gebruik IdentityServer (een OAuth/OpenID connect implementatie) om mijn API te beveiligen.

[ Voor 26% gewijzigd door whoami op 08-07-2019 17:06 ]

[Janoz]

whoami schreef op maandag 8 juli 2019 @ 17:04:
Ga je in dat geval dan helemaal zelf je token gaan opbouwen ?
Ik heb momenteel een REST api in .NET ontwikkelt, waarbij ik zelf ook controle heb over de users. Ik gebruik IdentityServer (een OAuth/OpenID connect implementatie) om mijn API te beveiligen.

Ik hint niet voor niks naar JWT . Moet voor .NET vast ook wel een mooie standaard implementatie voor te vinden. Bijkomend voordeel is dat je je service helemaal stateless kunt maken, en dus heel schaalbaar.

[egonolieux]

Voor jouw toepassing is OAuth nodeloos ingewikkeld. Gebruik inderdaad gewoon een token die je opvraagt middels Basic (mits het via https gaat!) of digest authentication. Kijk voor het token dan gelijk even naar JWT. Dan kun je je REST service helemaal stateless houden en heb je aan de serverkant ook geen sessie meer nodig.

Als ik het goed begrijp kan je met JWT o.a. een user ID als claim meegegeven, en door middel van de server secret key kan je de claims met een hmac (signature) authenticeren. Met stateless/geen sessie aan de server kant bedoel je geen access tokens en hun expiration dates bijhouden neem ik aan? Als de gebruiker de JWT bijhoudt voor toekomstige requests (HTTP-only cookie), moet je dan ook niet beschermen tegen CSRF? Wat doe je trouwens met token revocation bij een stateless server? Gewoon niet?

Die roles hoef je imho niet te integreren met scopes.
Scopes gebruik je -imho- om bepaalde operaties van je API af te bakenen. Ik zie het zo: om bepaalde operaties op een API uit te mogen voeren, heb je scope X nodig. Voor andere operaties binnen die API heb je scope Y nodig.

Maar in veel gevallen komen de scopes van de API overeen met de roles van gebruikers. Het is perfect mogelijk dat een client (app) een scope aanvraagt waar de geauthenticeerde user geen recht tot heeft. Wat doe je dan, gewoon negeren? De client (app) hiervan op de hoogte brengen?

[Hydra]

egonolieux schreef op dinsdag 9 juli 2019 @ 08:06:
Als ik het goed begrijp kan je met JWT o.a. een user ID als claim meegegeven, en door middel van de server secret key kan je de claims met een hmac (signature) authenticeren. Met stateless/geen sessie aan de server kant bedoel je geen access tokens en hun expiration dates bijhouden neem ik aan? Als de gebruiker de JWT bijhoudt voor toekomstige requests (HTTP-only cookie), moet je dan ook niet beschermen tegen CSRF? Wat doe je trouwens met token revocation bij een stateless server? Gewoon niet?

Heb er een tijd terug een een blog over geschreven.

In de basis: een JWT is gewoon een JSON object waarin je kwijt kan wat je wil. Dat ik user "Pietje" ben, en de rollen "Admin", "Opperbaas" en "Chefke" heb bijvoorbeeld. Dit token maak je aan als een user een login doet op een service, en de user stuurt dit mee bij ieder request (via header / cookie / whatever). Omdat je in dit token ook rechten / rollen hebt staan, hoef je niet iedere keer bij iedere actie van een gebruiken in een database of session store deze rechten op te zoeken.

De reden dat dit 'veilig' is, is simpel: deze tokens sign of encrypt je op de server met een geheime key, en alle services waar dit token op gebruikt wordt hebben diezelfde key en kunnen dus checken of de inhoud correct is.

Een van de issues van JWTs is token revocation: dit kan gewoon niet. Daarom zijn JWTs dus short-lived en moeten regelmatig gerefreshed worden.

Maar in veel gevallen komen de scopes van de API overeen met de roles van gebruikers. Het is perfect mogelijk dat een client (app) een scope aanvraagt waar de geauthenticeerde user geen recht tot heeft. Wat doe je dan, gewoon negeren? De client (app) hiervan op de hoogte brengen?

Je moet OAuth gewoon vergeten. Het is niet bedoeld voor 1 op 1 authenticatie/authorisatie. Als er geen 3 partijen zijn, (bijvoorbeeld jouw applicatie wil bij Facebook data van gebruikers) heb je het over het algemeen niet nodig.

Ik zou als ik jou was ook geen JWTs gebruiken; het voordeel van JWTs zie je vooral in grote microservice landschappen. Gewoon een login waarin je een session token krijgt aan de hand waarvan je de rechten opzoekt bij iedere request is veel simpeler.

[Janoz]

egonolieux schreef op dinsdag 9 juli 2019 @ 08:06:
Als ik het goed begrijp kan je met JWT o.a. een user ID als claim meegegeven, en door middel van de server secret key kan je de claims met een hmac (signature) authenticeren. Met stateless/geen sessie aan de server kant bedoel je geen access tokens en hun expiration dates bijhouden neem ik aan? Als de gebruiker de JWT bijhoudt voor toekomstige requests (HTTP-only cookie), moet je dan ook niet beschermen tegen CSRF? Wat doe je trouwens met token revocation bij een stateless server? Gewoon niet?

Met stateless/geen sessies bedoel ik inderdaad dat je op de server niks gebruikersspecifieks hoeft bij te houden. Zolang je de key kent kun je de jwt ontsleutelen, en controleren dat de gegevens niet veranderd zijn. Je zou de userId er in kunnen zetten, maar ook de rollen waarvoor die user rechten heeft.

Verder moet je de lifetime van je token gewoon kort houden. De client weet hoe lang het cookie (nog) geldig is en kan hem gewoon refreshen. Revocation kun je doen door enkel de ingetrokken tokens bij te houden. Voor CSRF en XSS kun je oplossingen gebruiken die ook bij alle andere token gebaseerde oplossingen gebruikt worden.

[Hydra]

Janoz schreef op dinsdag 9 juli 2019 @ 09:19:
Revocation kun je doen door enkel de ingetrokken tokens bij te houden.

Hoe had je dat bedacht dan?

[Janoz]

Hydra schreef op dinsdag 9 juli 2019 @ 09:46:
[...]


Hoe had je dat bedacht dan?

UserId en timestamp bijhouden en alle tokens van die gebruiker die uitgegeven zijn voor timestamp afkeuren. Dit tupeltje distribueer je over al je nodes, maak je beschikbaar voor alle nodes, of implementeer je in een voorliggende firewall/proxy. Aanname is wel dat het aantal te revoken tokens over het algemeen minimaal is. Zodra de timestamp ouder is dan de lifetime van de tokens kun je hem schonen.

Eigenlijk hou je dus inderdaad niet de tokens bij, maar de gebruiker.

[ Voor 6% gewijzigd door Janoz op 09-07-2019 12:45 ]

[Hydra]

Janoz schreef op dinsdag 9 juli 2019 @ 12:42:
UserId en timestamp bijhouden en alle tokens van die gebruiker die uitgegeven zijn voor timestamp afkeuren. Dit tupeltje distribueer je over al je nodes, maak je beschikbaar voor alle nodes, of implementeer je in een voorliggende firewall/proxy.

Maar dan maak je dus het voornaamste voordeel van JWT's, dat je zonder lookups in een centrale plek weet wat een gebruiker mag, dan weer ongedaan. Je maakt het systeem zo behoorlijk complex. Dan kan je beter met een session state in een (bijvoorbeeld) gedeelde Redis instance werken. Dan heb je nog steeds die single source of truth, waarbij revocations wel instant zijn.

Je kunt dan ook, in het geval van microservices, gewoon in je API gateway deze lookup doen en als deze slaagt (credentials zijn valid) het user-object als header meesturen naar het achterland zodat deze altijd in de request context beschikbaar is. Da's bijvoorbeeld hoe de mobiele back-end van de ING het doet.

Di's een veelvoorkomend probleem met het toepassen van JWTs: laagjes erop bouwen om de 'problemen' op te lossen. In plaats van 'gewoon' geen JWTs te gebruiken. My 2 cents.

[Janoz]

Hydra schreef op dinsdag 9 juli 2019 @ 13:05:
[...]


Maar dan maak je dus het voornaamste voordeel van JWT's, dat je zonder lookups in een centrale plek weet wat een gebruiker mag, dan weer ongedaan. Je maakt het systeem zo behoorlijk complex. Dan kan je beter met een session state in een (bijvoorbeeld) gedeelde Redis instance werken. Dan heb je nog steeds die single source of truth, waarbij revocations wel instant zijn.

Ik ben het ook zeker niet met je oneens, ik gaf een mogelijke oplossing waarbij je uiteraard de vraag moet blijven stellen of de voordelen opwegen tegen de nadelen. Ik doe daarbij wel de aanname dat het aantal revoked keys, zeker in vergelijking met het aantal ingelogde gebruikers, extreem laag is. Gecombineerd met dat je een revoke nooit langer dan 5 minuten hoeft te onthouden krijg je een dermate klein lijstje dat de distributie lang zo zwaar niet is.

[egonolieux]

Als je de expiration time van de tokens op 5 minuten houdt, heeft het dan nog wel zin revocations te doen? Ik denk tegen dat je het door hebt dat een token onderschept is, dat deze 5 minuten al lang voorbij zijn en de token tegen dan toch niet meer geldig is?

Ik ben het eens met Hydra dat het grootste voordeel van JWT weg valt als je server-side de revocations moet beginnen beheren. Het niet langer stateless en dan denk ik dat je evengoed een simpele random string als access token kunt gebruiken en deze bijhouden in de database aan de serverkant?

Je moet OAuth gewoon vergeten. Het is niet bedoeld voor 1 op 1 authenticatie/authorisatie. Als er geen 3 partijen zijn, (bijvoorbeeld jouw applicatie wil bij Facebook data van gebruikers) heb je het over het algemeen niet nodig.

ik ben reeds overtuigd geen OAuth te implementeren, maar blijf me toch conceptueel deze vraag stellen. Of het nu OAuth is of niet, meestal hebben gebruikers roles om hun toegang tot bepaalde informatie/acties af te schermen (zoals een role voor admin gebruikers). Ook al zijn er 3 partijen, is het de user die toestemming geeft aan een applicatie om bepaalde resources te mogen raadplegen. Dus wat als de app een scope aanvraagt die eigenlijnlijk enkel maar mogelijk is voor admin gebruikers en een niet-admin gebruiker keurt het goed?

De API van github bijvoorbeeld gebruikt ook OAuth, dus ik kan me niet voorstellen dat GitHub speciaal voor zichzelf een aparte API zal bouwen die niet met OAuth werkt omdat ze de eigenaar van de app zijn (slechts 2 partijen)? Het lijkt me perfect mogelijk elke situatie in te beelden als 3 partijen; je maakt gewoon geen onderscheid tussen eigen apps of apps van andere partijen.

[ Voor 7% gewijzigd door egonolieux op 10-07-2019 07:52 ]

[Voutloos]

egonolieux schreef op woensdag 10 juli 2019 @ 07:49:
Als je de expiration time van de tokens op 5 minuten houdt, heeft het dan nog wel zin revocations te doen? Ik denk tegen dat je het door hebt dat een token onderschept is, dat deze 5 minuten al lang voorbij zijn en de token tegen dan toch niet meer geldig is?

Sure, voor het huidige token is het risico wat ingeperkt. Maar hoe weet je dan of een bepaald token mag worden vernieuwd?

[egonolieux]

Voutloos schreef op woensdag 10 juli 2019 @ 08:09:
[...]
Sure, voor het huidige token is het risico wat ingeperkt. Maar hoe weet je dan of een bepaald token mag worden vernieuwd?

Is het niet zo dat een token voor dezelfde gebruiker nooit hetzelfde is? Bij het aanvragen van een token schuift de expiration date telkens op dus verandert de token en zijn signature mee. Of begrijp ik hier iets verkeerd?

[Hydra]

egonolieux schreef op woensdag 10 juli 2019 @ 07:49:
Als je de expiration time van de tokens op 5 minuten houdt, heeft het dan nog wel zin revocations te doen? Ik denk tegen dat je het door hebt dat een token onderschept is, dat deze 5 minuten al lang voorbij zijn en de token tegen dan toch niet meer geldig is?

Je kunt met JWTs simpelweg geen revocations doen zonder het distributed aspect volledig om zeep te helpen, en daarom wordt vaak gekozen voor een korte expiration time. Het is het een of het ander. Als je een revocation mechanisme bouwt, heeft die korte expiration time geen nut meer.

Ik ben het eens met Hydra dat het grootste voordeel van JWT weg valt als je server-side de revocations moet beginnen beheren. Het niet langer stateless en dan denk ik dat je evengoed een simpele random string als access token kunt gebruiken en deze bijhouden in de database aan de serverkant?

Precies. En da's eigenlijk gewoon een sessie met sessie ID. De meeste web/REST frameworks supporten dat out of the box.

ik ben reeds overtuigd geen OAuth te implementeren, maar blijf me toch conceptueel deze vraag stellen. Of het nu OAuth is of niet, meestal hebben gebruikers roles om hun toegang tot bepaalde informatie/acties af te schermen (zoals een role voor admin gebruikers). Ook al zijn er 3 partijen, is het de user die toestemming geeft aan een applicatie om bepaalde resources te mogen raadplegen. Dus wat als de app een scope aanvraagt die eigenlijnlijk enkel maar mogelijk is voor admin gebruikers en een niet-admin gebruiker keurt het goed?

Dit is extreem applicatie specifiek dus je zult hier geen simpel antwoord op krijgen. OAuth scopes zijn in essentie gewoon rollen, alleen worden deze in het resource-denken vaak gebruikt om te bepalen welke resources een gebruiker wat op mag doen. RBAC aan de andere kant werkt vanuit rollen en groepen, en redeneert vanuit 'wie' je bent in de applicatie wat je dan mag. Het lijkt op elkaar, maar het is ook weer anders. Je zou het kunnen mappen.

De API van github bijvoorbeeld gebruikt ook OAuth, dus ik kan me niet voorstellen dat GitHub speciaal voor zichzelf een aparte API zal bouwen die niet met OAuth werkt omdat ze de eigenaar van de app zijn (slechts 2 partijen)? Het lijkt me perfect mogelijk elke situatie in te beelden als 3 partijen; je maakt gewoon geen onderscheid tussen eigen apps of apps van andere partijen.

Dergelijke API's werken zo omdat je ten eerste wel 3 partijen hebt; Github, een user, en een 3rd party (bijvoorbeeld je CI/CD tooling) die toegang hebt. Daarnaast heb je daar vaak je dat ook gewoon via een API secret token gebruik kan maken. Dus vaak bieden ze meerdere manieren aan, afhankelijk van of de applicatie interactief om toegang kan vragen.

In jouw geval kun je OAuth gebruiken, alleen is het voor je gebruikers niet gebruiksvriendelijk.

egonolieux schreef op woensdag 10 juli 2019 @ 08:15:
Is het niet zo dat een token voor dezelfde gebruiker nooit hetzelfde is? Bij het aanvragen van een token schuift de expiration date telkens op dus verandert de token en zijn signature mee. Of begrijp ik hier iets verkeerd?

An sich correct maar het maakt in princiepe niet uit. Je hoeft niet bij een revocation mechanisme (wat an sich al fout is) niet het hele token dat invalid is op te slaan; gewoon alleen een user-id (wat ook in je token staat) en een timestamp waarvoor alles invalid is op te slaan. Vergeet ook niet dat een standaard JWT signed is, en niet encrypted. Iedereen die toegang heeft kan dus de content lezen, aanpassen heeft alleen geen zin.

[ Voor 11% gewijzigd door Hydra op 10-07-2019 08:47 ]

[egonolieux]

Dit is extreem applicatie specifiek dus je zult hier geen simpel antwoord op krijgen. OAuth scopes zijn in essentie gewoon rollen, alleen worden deze in het resource-denken vaak gebruikt om te bepalen welke resources een gebruiker wat op mag doen. RBAC aan de andere kant werkt vanuit rollen en groepen, en redeneert vanuit 'wie' je bent in de applicatie wat je dan mag. Het lijkt op elkaar, maar het is ook weer anders. Je zou het kunnen mappen.

Er is niet veel over te vinden, maar als je in de RFC kijkt, staat er dat de authorization server scopes kan weigeren en dat de effectieve scopes als parameter aan de client teruggegeven moeten worden als dat het geval is. De client kan dan misschien een boodschap tonen dat niet alle aangevraagde scopes kunnen gebruikt worden.

An sich correct maar het maakt in princiepe niet uit. Je hoeft niet bij een revocation mechanisme (wat an sich al fout is) niet het hele token dat invalid is op te slaan; gewoon alleen een user-id (wat ook in je token staat) en een timestamp waarvoor alles invalid is op te slaan. Vergeet ook niet dat een standaard JWT signed is, en niet encrypted. Iedereen die toegang heeft kan dus de content lezen, aanpassen heeft alleen geen zin.

Wat ik bedoelde is dat als iemand een access token onderschept, hij deze toch maar maximaal 5 minuten kan gebruiken omdat elke nieuwe token anders is door de nieuwe expiration date. Het maakt op zich niet uit of de token leesbaar is als hij enkel een user ID bevat (alsook andere zaken als roles); dit lijkt me geen geheime informatie. De aanvaller kan zelf de expiration date ook niet aanpassen omdat hij niet in bezit is van de private/secret key om een nieuwe signature te genereren.

[ Voor 31% gewijzigd door egonolieux op 10-07-2019 19:38 ]

[Hydra]

egonolieux schreef op woensdag 10 juli 2019 @ 19:18:
Er is niet veel over te vinden, maar als je in de RFC kijkt, staat er dat de authorization server scopes kan weigeren en dat de effectieve scopes als parameter aan de client teruggegeven moeten worden als dat het geval is. De client kan dan misschien een boodschap tonen dat niet alle aangevraagde scopes kunnen gebruikt worden.

Alles kan. De vraag is of het nut heeft.

Wat ik bedoelde is dat als iemand een access token onderschept, hij deze toch maar maximaal 5 minuten kan gebruiken omdat elke nieuwe token anders is door de nieuwe expiration date.

Klopt.