Hoe REST beveiligen?

[HollowGamer]

Mijn vraag
- Website => https://example.com
- REST => https://example.api (ander domain dus)

Stel je logt in op de website, en je wilt nu gebruik maken van de API (https://example.api/books/order/by-name), hoe beveilig je dan deze API? M.a.w. hoe weet de API dat hij met dezelfde gebruiker praat als diegene die is ingelogd op https://example.com?

Ik lees verschillende oplossingen, maar ik op elke methode is een opmerking:

HTTP Basic Auth
https://user:[e-mail]/.. => Niet veilig, want er wordt gebruik gemaakt van een zwakke encryptie van het wachtwoord. Tevens het idee dat een wachtwoord opneemt in de URL, lijkt me geen goed idee. Dit kan je uiteraard ook gewoon vervangen door iets anders.

Het is ook mogelijk gebruik te maken van digit, maar ook deze heeft de bovenstaande nadelen, en is ook niet zo flexibel.

Opnemen in url
https://example.api/key/..

Dit lijkt de meest handige, aangezien deze vrij makkelijk is te implementeren (+ tijdstamp, etc.).
De URL wordt wat ik begrijp encrypt. Echter zou iemand deze uit de cache kunnen halen.
De key zou je kunnen vasthouden, en zo maar één sessie toestaan, maar dit is misschien niet zo handig als je op meerdere locaties tegelijk bent ingelogd (tablet + PC bijv.).

Dit zou ook kunnen: https://example.api/authenticate (met een POST), en bij elke request dit weer valideren.

Sessie/Cookies
Dit wordt overal afgeraden. In theorie zou je dus de sessie kunnen meegeven, en vervolgens deze checken op welke gebruiker, start datum, agent, etc. is. Echter kan je ook een sessie 'makkelijk' spoofen.

Verder wordt er gesproken over de (sessie) storage-backend die tegenwoordig in elke browser zit, echter kun je deze ook uitschakelen, waardoor deze mogelijkheid weer wegvalt.

oAuth, JWT, ..
Deze lijken best ingewikkeld en zijn nog volop in ontwikkeling (wat ik heb gelezen).
JWT lijkt hierin de beste oplossing te zijn, maar wederom niet geheel duidelijk hoe je dit makkelijk kunt implementeren.

Relevante software en hardware die ik gebruik
PHP, JSON, nodejs (beginner)

Wat ik al gevonden of geprobeerd heb
Topics op Stackoverflow, blogs, etc. maar heb nog vragen.

Bedankt.

[Pizzalucht]

Je zou een authenticate call kunnen maken. In deze authenticate call stuur je een key en een secret terug.
In elke call zet je de key in de HTTP headers en genereer je een signature aan de hand van secret en wat andere variabelen. Die HTTP headers valideer je dan aan de server kant. De key en secret moet je dan natuurlijk ook aan de serverkant hebben opgeslagen.

Leesvoer: http://bitoftech.net/2014...tion-hmac-authentication/

De voorbeeldcode is dan wel in ASP, maar je kan de code ook makkelijk implementeren in PHP/Javascript/NodeJS, HMAC is overal te gebruiken.

In het voorbeeld gebruiken ze de Authorization header, maar je kan ook gewoon custom headers gebruiken, bijvoorbeeld:
X-Auth-Key
X-Auth-Nonce

[DaCoTa]

Gebruiker via website een API key aan laten maken met een secret en de payload van je request signen met de secret, inclusief een nonce (teller). Zowel de key als de sign in een header toe laten voegen en iedere request verifieren. De meeste bitcoin beurzen hebben een dergelijke REST api, de documentatie van https://developers.quoine.com/#authentication is vrij duidelijk als voorbeeld.

[Hydra]

Heb een tijdje terug een post over JWT's geschreven: http://www.niels.nu/blog/2015/json-web-tokens.html

Het is verder een beetje afhankelijk van wat je precies wil, wat belangrijk voor je is en welk framework je gebruikt. JWTs zijn relatief simpel te gebruiken en er zijn genoeg frameworks die ze ondersteunen.

[Verwijderd]

Voor Laravel zijn er wel wat leuke oplossingen:
JWT: https://github.com/tymondesigns/jwt-auth
OAuth2: https://laravel.com/docs/5.3/passport

Ik gebruik zelf JWT voor mijn project omdat ik er al bekend mee was en Laravel Passport nog niet zo lang bestaat. Sowieso zal HTTPS geen overbodige luxe zijn maar dat moet wel lukken via Let's Encrypt.

[Juup]

https + basic/digest auth?
Klaar.

[Ramon]

Juup schreef op zondag 25 september 2016 @ 11:01:
https + basic/digest auth?
Klaar.

Nee.

[johnkeates]

Juup schreef op zondag 25 september 2016 @ 11:01:
https + basic/digest auth?
Klaar.

Nee.

[Usselite]

Voor een eigen project gebruik ik HTTPS + Basic, ECDH met AES (met IV en Salt) per client voor individuele versleuteling van het transport van data. Nu moet ik wel zeggen, de API moet alleen zorgen voor een veilig transport, vandaar de keuze van AES, inlog wordt extern geregeld.

[Webgnome]

Ik zou zeggen implementeer een /login call waarbij de gebruiker zijn gebruikersnaam/wachtwoord moet opvoeren. (dan kan gewoon basic en https...) Vervolgens krijgt de caller in kwestie een token die bij elk request moet worden mee gestuurd. Elke keer controleer je die token en als die geldig is laat je het request door. Een tweede call naar login voor dezelfde gebruiker zorgt er voor dat alle tokens van die gebruiker worden verwijderd en een nieuwe token de juiste is.

[Verwijderd]

Webgnome schreef op zondag 25 september 2016 @ 13:25:
Ik zou zeggen implementeer een /login call waarbij de gebruiker zijn gebruikersnaam/wachtwoord moet opvoeren. (dan kan gewoon basic en https...) Vervolgens krijgt de caller in kwestie een token die bij elk request moet worden mee gestuurd. Elke keer controleer je die token en als die geldig is laat je het request door. Een tweede call naar login voor dezelfde gebruiker zorgt er voor dat alle tokens van die gebruiker worden verwijderd en een nieuwe token de juiste is.

Dit is precies wat JWT doet afgezien van het oude tokens invalid maken (wanneer je elder inlogt). JWT heeft tevens een TTL (time to live) waardoor je zelf niet hoeft te kijken of hij nog valid is. Daarnaast kun je hem refreshen waardoor je een andere token krijgt.

[Ventieldopje]

Waarom niet gewoon de authentication bearer <api key> header gebruiken? Of JWT of Oauth.. de eerste is makkelijk te implementeren en voor de andere zijn veel libraries beschikbaar.

Niet ontwikkeld/stabiel is onzin..

Webgnome schreef op zondag 25 september 2016 @ 13:25:
Ik zou zeggen implementeer een /login call waarbij de gebruiker zijn gebruikersnaam/wachtwoord moet opvoeren. (dan kan gewoon basic en https...) Vervolgens krijgt de caller in kwestie een token die bij elk request moet worden mee gestuurd. Elke keer controleer je die token en als die geldig is laat je het request door. Een tweede call naar login voor dezelfde gebruiker zorgt er voor dat alle tokens van die gebruiker worden verwijderd en een nieuwe token de juiste is.

En dan ben je bezig met je API en vervolgens roep je een tweede script aan die ook de API gebruikt en de login call doet ... hoppa, gaat je andere script de mist in. Lijkt mij niet helemaal de bedoeling

Maar goed hier zijn dus al lang standaard oplossingen voor. Why invent the weel?

offtopic:
De reden waarom je met JWT wél van token kan refreshen is omdat deze niet ál je tokens de deur uit gooit maar alleen de gene die verlopen zijn.

[ Voor 72% gewijzigd door Ventieldopje op 25-09-2016 14:54 ]

[Hydra]

Ventieldopje schreef op zondag 25 september 2016 @ 14:23:
Waarom niet gewoon de authentication bearer <api key> header gebruiken? Of JWT of Oauth..

Of gewoon beide Hoe je een token bij elkaar frutselt en hoe dat token opgebouwd is, staat gewoon los van elkaar JWTs werken prima samen met Oauth. Het voornaamste voordeel van een JWT is dat je niet naderhand in een DB hoeft te checken of 'ie valid is.

[Ventieldopje]

Hydra schreef op zondag 25 september 2016 @ 16:55:
[...]


Of gewoon beide Hoe je een token bij elkaar frutselt en hoe dat token opgebouwd is, staat gewoon los van elkaar JWTs werken prima samen met Oauth. Het voornaamste voordeel van een JWT is dat je niet naderhand in een DB hoeft te checken of 'ie valid is.

Dmv caching zal dat geen probleem mogen zijn De implementatie van puur alleen de authentication header is veel simpeler dan jwt en/of oauth. Allemaal zijn voor en nadelen.

[ Voor 12% gewijzigd door Ventieldopje op 25-09-2016 18:03 ]

[Cartman!]

Ventieldopje schreef op zondag 25 september 2016 @ 17:59:
[...]


Dmv caching zal dat geen probleem mogen zijn De implementatie van puur alleen de authentication header is veel simpeler dan jwt en/of oauth. Allemaal zijn voor en nadelen.

En wat zet je dan in die header? Juist...een JWT bijvoorbeeld

[Ventieldopje]

Cartman! schreef op zondag 25 september 2016 @ 19:39:
[...]

En wat zet je dan in die header? Juist...een JWT bijvoorbeeld

Ehh, nee beide zijn andere dingen

[Cartman!]

Ventieldopje schreef op zondag 25 september 2016 @ 19:41:
[...]


Ehh, nee beide zijn andere dingen

Precies, JWT en een Authorization header zijn andere dingen en je kan ze heel goed samen gebruiken.

code:

Authorization: Bearer <JWT>

[ Voor 8% gewijzigd door Cartman! op 25-09-2016 19:45 ]

[P1nGu1n]

Overigens, https://example.api/books/order/by-name lijkt me geen mooi design en is niet ècht RESTful. Ik zou eerder kiezen voor iets als https://example.api/books?orderby=name

Qua beveiliging zou ik voor HMAC of JWT gaan.

[ Voor 12% gewijzigd door P1nGu1n op 25-09-2016 22:43 ]

[Hydra]

Ventieldopje schreef op zondag 25 september 2016 @ 17:59:
Dmv caching zal dat geen probleem mogen zijn

Caching is geen silver bullet. There's two things that are hard in computer programming; parallelism, cache invalidation and off by one errors

Maar serieus: het heeft significante voordelen als een service niet in de DB hoeft te checken of een token valid is. Niet alleen de hits op de database kwa performance maar vooral door de extra complexiteit die je aanbrengt. Als jij 20 verschillende services hebt die allemaal die DB of cache moeten benaderen heb je dus een behoorlijk tightly coupled systeem gebouwd.

Ventieldopje schreef op zondag 25 september 2016 @ 19:41:
Ehh, nee beide zijn andere dingen

Ja. Dat zeg ik; gamma. OAuth is een standaard voor het uitwisselen van een token. Dat token kan zo'n standard hex-string zijn die in een DB opgezocht wordt maar kan ook gewoon een JWT zijn. JWT past dus helemaal prima binnen een OAuth setup.

[ Voor 22% gewijzigd door Hydra op 26-09-2016 08:35 ]

[MeZZiN]

Kijk hoe andere het doen altijd goed zeker als ze ooit op de blaren hebben gezeten een grote bank...

Maar je kan voor de API CORS inregelen Wikipedia: Cross-origin resource sharing (er zijn vast betere sites)

Als je CORS gebruikt kan je POST PUT en GET doen zodat je in de URLS geen usernames en wachtwoorden hoeft op te sturen.

Dan tegen XSRF / CSRF voeg je padding toe aan elk request dan heb je het voor een deel opgelost en dan als laatste doe je een server header check (X-Requested-with). Als je helemaal fancy gaat geef je bij de login een token mee die je dan terug geeft in de headers. Waarbij de header check en als je voor fancy gaat ook het token checked.

Verder cookies en session hijacking zijn risicos alleen dan moet je wel tussen de SSL connectie gaan zitten. Alles is de doen maar lastig is het zeker. Maar je kan altijd als het nodig is nog een IP <-> session check doen om te kijken de sessie klopt nog met de IP dat het gestart heeft. Let op dit kan issues opleveren met grote partijen zoals grote bedrijven waarbij de meerdere externe IP adressen gebruik wordt. Dit uitvogelen en test case te maken met de klant is welke IP adressen ze zelf gebruiken is een groot feest.

En cache gebruik memcached of een van de varianten werkt super zet de TTL goed en gaan.

OAuth is een prima standaard maar je moet altijd een alternatief hebben met een normale login.

Wat je moet doen is zorgen dat jij beter beveiligd bent dan de rest.

[Verwijderd]

@TS: Ik zou toch eens proberen om je wat in te lezen in Oauth 2.0. oAuth is juist bedoeld om op een simpele en gestandaardiseerde manier authenticatie af te handelen. Dat maakt het voor anderen ook makkelijk om met jouw API te praten, en voor jou makkelijk om per consumer van jouw API credentials te beheren (of: in te trekken).

johnkeates schreef op zondag 25 september 2016 @ 11:04:
[...]

Nee.

Ramon schreef op zondag 25 september 2016 @ 11:02:
[...]

Nee.

offtopic:
Misschien handig om even toe te lichten waarom https + basic auth volgens jullie geen goede oplossing is, in plaats van een "Nee.".

[pedorus]

HollowGamer schreef op zaterdag 24 september 2016 @ 22:39:
HTTP Basic Auth
https://user:[e-mail]/.. => Niet veilig, want er wordt gebruik gemaakt van een zwakke encryptie van het wachtwoord. Tevens het idee dat een wachtwoord opneemt in de URL, lijkt me geen goed idee. Dit kan je uiteraard ook gewoon vervangen door iets anders.

Het is ook mogelijk gebruik te maken van digit, maar ook deze heeft de bovenstaande nadelen, en is ook niet zo flexibel.

Https is zeker geen zwakke encryptie, tenzij je deze verkeerd weet te configureren, maar dan maakt de authenticatiemethode nauwelijks meer uit verder (tenzij je ook die compleet vernacheld). Voor de rest gebruikt HTTP Basic Auth geen encryptie, er is sprake van een encoding die mensen toevallig wat slecht kunnen lezen als je het in ascii ziet. Deze encoding is er alleen zodat gekke tekens in wachtwoorden ook werken. De gegevens worden niet zozeer in de url verstuurd, maar in een header zoals "Authorization: Basic YXBpdXNlcjphcGlwd2Q=".

In tegenstelling tot de 3(+) mensen die nee zeggen zonder beredenering zou ik voor een simpel projectje basic auth gewoon doen, als er weinig bijzonders te beveiligen is. Een beetje zoals Tweakers hier, jarenlang waren sessies over onbeveiligde verbindingen over te nemen omdat http gebruikt werd, maar dit heeft niet tot echte problemen geleid omdat er eigenlijk niet heel veel te halen valt. Als je denkt dat het voor een service goed genoeg is om service-wachtwoorden plain text in een configuratiebestand te zetten, dan is basic auth waarschijnlijk meer dan voldoende. Als wachtwoorden gehashed opgeslagen zijn, dan valt voor de meeste dingen 0.1 seconden hashtijd per request nog wel te overzien. Meestal is de hashtijd helaas veel korter, maar dit komt omdat verouderde hashfuncties worden gebruikt. Als het te gek wordt (veel verwachte requests) dan kun je iets als Basic Auth gebruiken om een JWT te genereren als het echt drukker wordt.

Het is trouwens in het algemeen een goed idee om het wachtwoord voor een normale gebruiker en een wachtwoord of token voor een api-user niet hetzelfde te laten zijn. Of dit van toepassing is, hangt van het type website af.

Opnemen in url
https://example.api/key/..

Klinkt ingewikkelder, want niet-standaard, en minder veilig ivm caching en delen van urls.

Sessie/Cookies
Dit wordt overal afgeraden. In theorie zou je dus de sessie kunnen meegeven, en vervolgens deze checken op welke gebruiker, start datum, agent, etc. is. Echter kan je ook een sessie 'makkelijk' spoofen.

Verder wordt er gesproken over de (sessie) storage-backend die tegenwoordig in elke browser zit, echter kun je deze ook uitschakelen, waardoor deze mogelijkheid weer wegvalt.

Waarom is dit "overal afgeraden"? Als je de REST api vanuit een browser gebruikt, dan zou ik niet weten waarom een sessie-cookie over https onveilig zou zijn. Tweakers bijvoorbeeld hier werkt ook gewoon met sessies, zie er weinig problemen. In essentie is JWT ook een sessie met alle informatie in de token (analoog aan het 'cookie').

Het voordeel en tevens nadeel van Basic Auth voor alle endpoints is dat je geen apart initieel authenticatiepunt nodig hebt. Het is ook combineerbaar: Basic Auth voor initiële authentificatie.

oAuth, JWT, ..

Je kan mooi en fancy willen doen en niet snappen wat er gebeurd, maar voor je het weet gaat het dan juist mis. Zie voor JWT bijvoorbeeld https://auth0.com/blog/cr...json-web-token-libraries/ . Voor OAuth zijn er ontelbare gevallen van mensen die hun secret tokens plaatsen in scriptjes als ze om hulp vragen. Ik acht daarom de kans een stuk groter dat iets dergelijks fout gaat, dan dat je een probleem krijgt met een standaard implementatie van Basic Auth.

[ZaZ]

pedorus schreef op maandag 26 september 2016 @ 23:07:
[...]

Voor de rest gebruikt HTTP Basic Auth geen encryptie, er is sprake van een encoding die mensen toevallig wat slecht kunnen lezen als je het in ascii ziet. Deze encoding is er alleen zodat gekke tekens in wachtwoorden ook werken. De gegevens worden niet zozeer in de url verstuurd, maar in een header zoals "Authorization: Basic YXBpdXNlcjphcGlwd2Q=".

Ohjee

[Elijan9]

HollowGamer schreef op zaterdag 24 september 2016 @ 22:39:
HTTP Basic Auth
https://user:[e-mail]/.. => Niet veilig, want er wordt gebruik gemaakt van een zwakke encryptie van het wachtwoord. Tevens het idee dat een wachtwoord opneemt in de URL, lijkt me geen goed idee. Dit kan je uiteraard ook gewoon vervangen door iets anders.

Bij Basic Authorization worden username en wachtwoord juist niet via de URL verstuurd, maar via een HTTP Header. (Jouw voorbeeld lijkt me meer een feature van een browser om de username en wachtwoord niet apart op te hoeven geven?)

ZaZ schreef op maandag 26 september 2016 @ 23:31:
[...]

Ohjee

Met HTTPS kunnen alleen de zender en ontvanger zien wat er verstuurd/ontvangen wordt qua HTTP headers (en welke URL gebruikt is) want al het HTTP verkeer is dan versleuteld. Als je inlogt bij jouw bank via een Form wordt ook alles ook onversleuteld verstuurd over een HTTPS verbinding, net zoals de creditcardgegevens bij een webshop enzovoort. Als ik kijk naar sommige reacties hier dan kan dit als een schok over komen

Ikzelf zou Basic Authorization dan ook goed genoeg vinden in combinatie met HTTPS, maar je zou natuurlijk ook Digest-MD5 of NTLM Authorization kunnen gebruiken...

[ZaZ]

Ik doelde slechts op de opmerking dat het geen encryptie is en refereerde naar een hele lange discussie van vorig jaar waar men het niet eens kon worden of zelfs base64 slechts encoding is of ook encryptie.

[Hydra]

ZaZ schreef op dinsdag 27 september 2016 @ 11:41:
Ik doelde slechts op de opmerking dat het geen encryptie is en refereerde naar een hele lange discussie van vorig jaar waar men het niet eens kon worden of zelfs base64 slechts encoding is of ook encryptie.

Ik denk dat developers het er helemaal prima over eens zijn dat base64 geen encryptie is. Oisyn vond het nodig gewoon ff lekker pedantic te wezen.

[ Voor 6% gewijzigd door Hydra op 27-09-2016 12:20 ]

[HollowGamer]

Bedankt voor alle reacties.

Pizzalucht schreef op zaterdag 24 september 2016 @ 23:07:
Je zou een authenticate call kunnen maken. In deze authenticate call stuur je een key en een secret terug.
In elke call zet je de key in de HTTP headers en genereer je een signature aan de hand van secret en wat andere variabelen. Die HTTP headers valideer je dan aan de server kant. De key en secret moet je dan natuurlijk ook aan de serverkant hebben opgeslagen.

Leesvoer: http://bitoftech.net/2014...tion-hmac-authentication/

De voorbeeldcode is dan wel in ASP, maar je kan de code ook makkelijk implementeren in PHP/Javascript/NodeJS, HMAC is overal te gebruiken.

In het voorbeeld gebruiken ze de Authorization header, maar je kan ook gewoon custom headers gebruiken, bijvoorbeeld:
X-Auth-Key
X-Auth-Nonce

Interessant, ga deze headers eens checken.

DaCoTa schreef op zondag 25 september 2016 @ 00:08:
Gebruiker via website een API key aan laten maken met een secret en de payload van je request signen met de secret, inclusief een nonce (teller). Zowel de key als de sign in een header toe laten voegen en iedere request verifieren. De meeste bitcoin beurzen hebben een dergelijke REST api, de documentatie van https://developers.quoine.com/#authentication is vrij duidelijk als voorbeeld.

Dat is zover ik begrijp wat JWT doet?

Hydra schreef op zondag 25 september 2016 @ 10:24:
Heb een tijdje terug een post over JWT's geschreven: http://www.niels.nu/blog/2015/json-web-tokens.html

Het is verder een beetje afhankelijk van wat je precies wil, wat belangrijk voor je is en welk framework je gebruikt. JWTs zijn relatief simpel te gebruiken en er zijn genoeg frameworks die ze ondersteunen.

Ga eens rustig op het gemak jou blogpost nalezen.
JWT zie ik veel terugkomen, zie op Packagist diverse oplossingen voorbij komen.

Juup schreef op zondag 25 september 2016 @ 11:01:
https + basic/digest auth?
Klaar.

Dat blijkt niet veilig te zijn, daarom vroeg ik mij af hoe ik dit beter zou kunnen oplossen.

Ventieldopje schreef op zondag 25 september 2016 @ 14:23:
Waarom niet gewoon de authentication bearer <api key> header gebruiken? Of JWT of Oauth.. de eerste is makkelijk te implementeren en voor de andere zijn veel libraries beschikbaar.

Niet ontwikkeld/stabiel is onzin..

JWT lijkt dan de beste oplossing.

Over Oauth heb ik gelezen dat er nu twee versies zijn (v1/v2), waarvan de laatste nog een concept is.
Tenminste dat ik lees ik terug op sommige blogs. Klopt dit?

Ik probeer hiermee aan te geven dat er eigenlijk nog niet echt een standaard oplossing is.
Bijvoorbeeld dat dit direct via de browser zelf zou kunnen, i.p.v. via libs.
Iedereen staat vrij om zelf een oplossing te kiezen, maar elke methode lijkt zo zijn nadelen te hebben.

pedorus schreef op maandag 26 september 2016 @ 23:07:
[...]

Ik bedoelde hierin digest, die wel encryptie gebruikt (dacht md5?).
Zou inderdaad prima voor basic auth kunnen kiezen, maar ik wil graag leren hoe het werkt en wat wordt aangeraden.

Sessies zouden kunnen worden 'gestolen' en het idee dat er wachtenwoorden over 'de lijn' worden gestuurd vind ik niet zo mooi. Weet niet precies hoe dit opgaat bij JWT, daar moet ik mij nog over inlezen.
Dat is ook de reden dat ik voor een al bedachte oplossing wil gaan, en niet zelf iets in elkaar wil zetten.

ZaZ schreef op maandag 26 september 2016 @ 23:31:
[...]

Ohjee

Iets met ouwe koeien.. tevens sluit het niet echt aan op dit topic.

Elijan9 schreef op dinsdag 27 september 2016 @ 11:23:
[...]


Bij Basic Authorization worden username en wachtwoord juist niet via de URL verstuurd, maar via een HTTP Header. (Jouw voorbeeld lijkt me meer een feature van een browser om de username en wachtwoord niet apart op te hoeven geven?)


[...]


Met HTTPS kunnen alleen de zender en ontvanger zien wat er verstuurd/ontvangen wordt qua HTTP headers (en welke URL gebruikt is) want al het HTTP verkeer is dan versleuteld. Als je inlogt bij jouw bank via een Form wordt ook alles ook onversleuteld verstuurd over een HTTPS verbinding, net zoals de creditcardgegevens bij een webshop enzovoort. Als ik kijk naar sommige reacties hier dan kan dit als een schok over komen

Ikzelf zou Basic Authorization dan ook goed genoeg vinden in combinatie met HTTPS, maar je zou natuurlijk ook Digest-MD5 of NTLM Authorization kunnen gebruiken...

Wikipedia: Basic access authentication
Dat kan op verschillende manieren; ik gebruikte als vb. URL encoding
Je zou ook een 'basic auth' kunnen doen d.m.v. een POST.
Het was meer als een manier van 'simple' login bedoeld.

Wat bedoel je precies met het laatste?
http://stackoverflow.com/...e-https-headers-encrypted
http://security.ittoolbox...ted-through-https-5221529

Ziet er naar uit dat ik mij maar eens opnieuw moet gaan verdiepen in REST en JWT.
Ik begrijp dat het je vrij staat hoe je REST implementeert, maar vroeg mij af of hier toch iets standaard in was afgesproken.
Zo zie je voorbeelden met https://example.com/api/user[s]/1, maar soms ook https://example.com/api/userdetails/1 of zelfs userDetails als part.
En opties/filters, worden die altijd meegeven aan de URL of verwerkt als header? Of is dit ook weer vrij?

Thanks.

[kwaakvaak_v2]

Ventieldopje schreef op zondag 25 september 2016 @ 14:23:
Waarom niet gewoon de authentication bearer <api key> header gebruiken? Of JWT of Oauth.. de eerste is makkelijk te implementeren en voor de andere zijn veel libraries beschikbaar.

Dat is exact wat ik nu ook gedaan heb om een redelijk simpele API in mijn eerste Laravel project af te schermen.

Super simpel uit de doos met Passport een personal access token per gebruiker aangemaakt (https://laravel.com/docs/5.3/passport#personal-access-tokens) en dan in de react-native client APP wordt die bearer token in de header gezet.

De gebruiker meld zich aan met zijn email + password, als deze correct is stuur de API de token terug naar de client en die wordt gebruikt om de daadwerkelijke content API calls te authenticeren. API server is enkel over HTTPS te benaderen. Al met al was ik binnen klein uurtje klaar met het afschermen van de API.

Zal vast niet 'bank' waterdicht zijn, maar voor wat de app moet kunnen is het meer dan afdoende.

Standaard verlopen die personal tokens na 100 jaar, maar dat was makkelijk op te lossen en ze verlopen nu nadat ze 14 dagen niet gebruikt zijn.

[ Voor 3% gewijzigd door kwaakvaak_v2 op 27-09-2016 14:15 ]

[Elijan9]

HollowGamer schreef op dinsdag 27 september 2016 @ 13:00:
[...]

Dat blijkt niet veilig te zijn, daarom vroeg ik mij af hoe ik dit beter zou kunnen oplossen.

Maar waar op baseer je dat dit niet veilig genoeg is? Als HTTPS met een goede encryptie erkend veilig genoeg is om creditcardgegevens onbewerkt te versturen, waarom zou een Basic Authorization header over HTTPS niet veilig zijn voor een REST service?

[...]

Wikipedia: Basic access authentication
Dat kan op verschillende manieren; ik gebruikte als vb. URL encoding
Je zou ook een 'basic auth' kunnen doen d.m.v. een POST.

Nee, dit interpreteer je verkeerd. Wat over de lijn gaat als een browser dit ondersteunt, is nog steeds een URL zonder username en wachtwoord en een HTTP header "Authorization". De gebruikersnaam en wachtwoord worden dus niet als URL meegegeven, overigens wordt de URL bij HTTPS óók versleuteld. En Basic Authorization gaat niet via POST-data, maar via een gestandaardiseerde HTTP header.

Wat bedoel je precies met het laatste?

Voor MD5 Digest authentication, zie o.a.:
Wikipedia: Digest access authentication
https://tools.ietf.org/html/rfc2617#section-3

[Verwijderd]

ZaZ schreef op dinsdag 27 september 2016 @ 11:41:
Ik doelde slechts op de opmerking dat het geen encryptie is en refereerde naar een hele lange discussie van vorig jaar waar men het niet eens kon worden of zelfs base64 slechts encoding is of ook encryptie.

offtopic:
Zoals ik het heb geleerd:

Encoding: data transformeren naar een ander (publiek toegankelijk) formaat zodat het gemakkelijk kan worden omgekeerd.
Encryption: data transformeren naar een ander formaat zodat het alleen voor bepaalde individuen omgekeerd (en dus gelezen) kan worden, tevens met als doel data confidentieel te houden.

Voorgaande zaken zeggen dus niets over het al dan niet ongedaan kunnen maken van de transformatie. Base64 lijkt mij hoe dan ook duidelijk _geen_ vorm van encryptie dus. Ik vind zelf deze pagina een hele duidelijke en goede bron van informatie omtrent deze onderwerpen.

[pedorus]

HollowGamer schreef op dinsdag 27 september 2016 @ 13:00:
Sessies zouden kunnen worden 'gestolen' en het idee dat er wachtenwoorden over 'de lijn' worden gestuurd vind ik niet zo mooi. Weet niet precies hoe dit opgaat bij JWT, daar moet ik mij nog over inlezen.

Bij JWT zul je vaak zien dat er ook een wachtwoord/token nodig is bij de initialisatie die ook gewoon over de lijn gaat. Op dezelfde manier als dat bij het inloggen hier op Tweakers het wachtwoord ook gewoon over de lijn gaat. Vervolgens heb je een sessietoken (vergelijkbaar met JWT).

Als je niet wil dat er herbruikbare wachtwoorden of tokens (zeg OAuth2 of JWT tokens) over de beveiligde lijn gaan, dan zijn client side certificates daarvoor een goede oplossing. Zie hier een mooie uitleg over de setup en het gebruik daarvan: http://nategood.com/clien...ate-authentication-in-ngi

De reden dat je ze bij Tweakers hier niet ziet, en veelal niet ziet ondanks dat het een schitterende oplossing is, is dat de setup wat ingewikkelder is. En hoe ingewikkelder de setup, hoe eerder er weer onnodig iets mis kan gaan. Of eerder hoe meer tijd je verspilt omdat mensen het niet snappen. Vandaar dat ik rustig Basic Auth blijf aanraden voor huis-tuin-en-keuken-gebruik.

In essentie is er trouwens weinig verschil tussen wat er over de lijn gaat bij Basic Auth, JWT, of OAuth2: dit is een herbruikbare token die indien hij uitlekt gebruikt kan worden door een aanvaller. Alleen een JWT verloopt vaak iets eerder (waarna je met een andere autorisatie een nieuwe moet laten maken). Grappig genoeg is qua beveiliging OAuth2 een stapje terug van OAuth1, bij OAuth1 ging er niet elk request een herbruikbare token over de lijn, net als bij de client side certificates. Echter, vanwege de reden die ik aangeef (te moeilijk voor developers) zijn ze hier weer van af gestapt bij OAuth2 omdat ze vonden dat HTTPS de boel veilig genoeg maakt voor verreweg de meeste gevallen.