[php] opzet authenticatie binnen API

[Anoniem: 331027]

Ik ben bezig om mijn eerste API op te zetten om een API-centric applicatie te bouwen. Doel: een API bouwen, waarop uiteindelijk een website en mobiele apps gebouwd kunnen worden. De API zal niet openbaar gebruikt gaan worden.

De applicatie is een applicatie waar gebruikers kunnen inloggen. Ik wil ze kunnen laten inloggen met een apart account, maar ook met Facebook, Twitter en Google-account. Nu loop ik volledig vast hoe ik de authenticatie kan regelen via de API. Ik heb veel gezocht en weet van de mogelijkheden van OAuth en Basic Auth. Ik ken het fenomeen van een private key.

Maar concreet kom ik er niet uit.
- Ik wil geen cookies/sessions gebruiken. Moet de username/password dan altijd als post-variabele meegestuurd worden met elke request?
- Facebook, Twitter en Google maken gebruiken van OAuth. Verplicht mij dat om dat zelf ook te gebruiken?

Ik hoop van harte dat iemand mij wat verder de juiste richting kan induwen

[Hydra]

Wat ik zelf onlangs gedaan heb is een 'inlog' op de API waarmee je 2 gehashte tokens terugkrijgt. Dit is de 'login' die verder gebruikt wordt voor alle communicatie. Dit zorgt ervoor dat je maar 1 maal het username / WW hoeft te versturen. Natuurlijk doe je dat versturen dan verder wel via SSL.

Dus:
/login?user=username&pass=password geeft 2 32 karakters lange tokens terug:
- id (hash gebaseerd op userID + salt)
- token: (hash gegenereerd voor die sessie, variabel)

Dan de rest van de API (standaard voorbeeld van een books API):
/books/1?id=<userid>&token=<token>

[Anoniem: 331027]

Dan moeten er dus bij elke request 2 tokens worden meegestuurd? Eigenlijk vergelijkbaar met iets als username en wachtwoord gehashed.
Maar als je de 2 tokens onderschept, dan kan je de sessie ook verder overnemen en alles doen voor die user.

Het ziet er verder uit als een lekkere eenvoudige oplossing, maar is dit veilig genoeg?

[Barryvdh]

Maar waarom zou je niet gewoon Oauth (1 zonder SSL of 2 met SSL) gebruiken? Dat is toch een bewezen techniek, in plaats van zelf iets bedenken met hashes ed.

[Anoniem: 331027]

Barryvdh schreef op dinsdag 11 maart 2014 @ 16:30:
Maar waarom zou je niet gewoon Oauth (1 zonder SSL of 2 met SSL) gebruiken? Dat is toch een bewezen techniek, in plaats van zelf iets bedenken met hashes ed.

Voornaamste reden: oauth is stukje complexer dan zelf een paar hashes heen en weer sturen. Ik vraag me af of voor zo'n 'interne' API oAuth echt nodig is.

[Cartman!]

OAuth2 is helemaal niet complex, sterker nog...dat is niet meer dan een string (access token) met je request meesturen in get, post of headers.

Zelf doe ik wat Hydra al omschrijft maar dan met 1 string wat id/token van de user bevat en een signature gebaseerd op een server secret/ Als er een request binnen komt met een access token dan valideer ik de signature, dan pak ik het id en als het token erbij matcht (in pricipe altijd want anders zou ermee geknoeid zijn) dan heb ik dmv 1 primary key search de huidige ingelogde user al.

[Hydra]

Anoniem: 331027 schreef op dinsdag 11 maart 2014 @ 16:26:
Dan moeten er dus bij elke request 2 tokens worden meegestuurd? Eigenlijk vergelijkbaar met iets als username en wachtwoord gehashed.

Nee, want het 'token' verandert steeds tussen sessies. Daarnaast kun je vanuit zowel de id en de token de user niet herleiden.

Maar als je de 2 tokens onderschept, dan kan je de sessie ook verder overnemen en alles doen voor die user.

Daarom gebruik je SSL.

Het ziet er verder uit als een lekkere eenvoudige oplossing, maar is dit veilig genoeg?

Voor wat? Betalingsverkeer? Nee. Voor een chatbox? Ja.

Cartman! schreef op dinsdag 11 maart 2014 @ 16:44:
Zelf doe ik wat Hydra al omschrijft maar dan met 1 string wat id/token van de user bevat en een signature gebaseerd op een server secret/ Als er een request binnen komt met een access token dan valideer ik de signature, dan pak ik het id en als het token erbij matcht (in pricipe altijd want anders zou ermee geknoeid zijn) dan heb ik dmv 1 primary key search de huidige ingelogde user al.

Die 'token' van mij is dus het server secret deel, alleen zijn het dan 2 aparte parameters i.p.v. 1 grote string.

[ Voor 30% gewijzigd door Hydra op 11-03-2014 17:22 ]

[Anoniem: 331027]

Nee, want het 'token' verandert steeds tussen sessies. Daarnaast kun je vanuit zowel de id en de token de user niet herleiden.

Ik wil graag de gebruiker langer ingelogd laten zijn dan alleen de sessie, bijv. 2 weken. Is dat op deze manier wel te tacklen?

[Cartman!]

Als je zelf je session handling doet wel.

[Anoniem: 331027]

Vanuit de API wil ik niks met cookies of sessies doen, uiteraard is de applicatie daarin vrij om te gebruiken, maar dan moet ik niet na 1 week de token gaan aanpassen.

Ik wil eigenlijk dat als de gebruiker elke week de app gebruikt, deze nooit uitlogt. Betekent dus dat ik elke 2 weken wel een nieuwe token moet versturen naar de app, zodat ze dan deze kunnen gebruiken. (zonder dat gebruiker weer opnieuw moet inloggen)

[ Voor 58% gewijzigd door Anoniem: 331027 op 11-03-2014 18:22 ]

[Barryvdh]

Volgens mij zitten refresh tokens ook in de spec van OAuth2

[Hydra]

Barryvdh schreef op dinsdag 11 maart 2014 @ 18:51:
Volgens mij zitten refresh tokens ook in de spec van OAuth2

Nadeel van de spec is dat tegen de tijd dat je 'em doorgelezen hebt dit zelf al geimplementeerd hebt Maar ik zou zeker, als je dit soort dingen gaat hergebruiken, voor OAuth gaan. Daarnaast had ik het hele delegation spul niet nodig.

Ook wel leuk om te lezen: http://hueniverse.com/201...2-0-and-the-road-to-hell/

[ Voor 15% gewijzigd door Hydra op 11-03-2014 19:00 ]

[Cartman!]

OAuth is goed maar verouderd imo, hopelijk dat er snel iets van OAuth3 kan komen die de veiligheid van OAuth combineert met de simpelheid van OAuth2. Ik vind Facebook wel het meest vooruitstrevend hierin, die bieden al opties om een access token alleen geldig te laten zien met de bijhorende app secret bijv. OAuth mist gewoon opties om clientside te werken omdat je de secret beschikbaar moet maken.