[PHP] Zelf API bouwen, hoe sessies/inloggen?

[Anoniem: 426269]

Sinds begin deze maand ben ik me wat aan het verdiepen in React en Angular (en dus ook Node.js). Het valt me op dat alle queries via een voorbeeld API gaan. Althans, die ik in de tutorials tot nu heb gedaan.
O.a. de Star Wars API https://swapi.co/. Erg handig. Maar hoe zit het nu met inloggen en sessie?

Voorheen deed ik alles inéén met PHP en jQuery (en MySQL), dus zonder API. Dan is in-/uitloggen en bijvoorbeeld winkelmandjes-inhoud goed te doen met sessies en cookies. Maar hoe gaat dat ongeveer in zijn werk met een API? Ik zag deze 5 jaar oude post [php] opzet authenticatie binnen API hier op het forum staan en daar hebben ze het o.a. over Oauth2. Ik begrijp dat er dan niet iets zoals een sessie meer is (en een cookie om te zien of je nog ingelogd bent), klopt dat? Dus dat er altijd een username en wachtwoord combi versleuteld wordt meegestuurd naar de API, klopt dat? Of zit ik er nu helemaal naast? Als iemand een zetje in de goede richting kan geven, graag!

[Room42]

Met API's is het gebruikelijk dat er een API Key gebruikt wordt voor de authenticatie (of autorisatie). Dat is een lange, random string, gekoppeld aan het gebruikersaccount. Meestal heeft de gebruiker zelf de optie om een nieuwe key te genereren, voor het geval dat ze de oude willen laten verlopen (om veiligheidsredenen).

Maar dan heb je dus nog steeds gebruikersauthenticatie nodig. Hoe je dat opzet (oath of een eigen systeem), mag je zelf weten

Dit is wellicht interessant: https://cloud.google.com/.../openapi/when-why-api-key

[ Voor 10% gewijzigd door Room42 op 27-05-2019 20:03 ]

[EnnaN]

Anoniem: 426269 schreef op maandag 27 mei 2019 @ 19:54:
...daar hebben ze het o.a. over Oauth2.

Dat is wat je wil. Neem een goeie Oauth2 library en implementeer die.

Ik begrijp dat er dan niet iets zoals een sessie meer is (en een cookie om te zien of je nog ingelogd bent), klopt dat? Dus dat er altijd een username en wachtwoord combi versleuteld wordt meegestuurd naar de API, klopt dat? Of zit ik er nu helemaal naast? Als iemand een zetje in de goede richting kan geven, graag!

REST (of RESTful) API's wordt veel mee gedaan, en een van de eigenschappen van zo'n ding is dat het stateless is. Elk verzoek heeft dus alles in zich, en je hebt geen sessie meer. Als je bij oauth kijkt hoef je niet perse een wachtwoord/username te hebben elke keer: wat je meestal doet is met een API key, waarmee je dan weer een (al dan niet tijdelijk) token ophaalt.

[Anoniem: 426269]

Room42 schreef op maandag 27 mei 2019 @ 19:59:
Met API's is het gebruikelijk dat er een API Key gebruikt wordt voor de authenticatie. Dat is een lange, random string, gekoppeld aan het gebruikersaccount. Meestal heeft de gebruiker zelf de optie om een nieuwe key te genereren, voor het geval dat ze de oude willen laten verlopen (om veiligheidsredenen).

Okee, moet ik dat dan zien als dat er in de user tabel naast het (auto)id, username en wachtwoord ook nog een veldje is met die lange, random string? En dat daar gewoon op gezocht wordt .i.p.v. de username en wachtwoord combi? De eerste keer bij inloggen moet ik het wel ergens tegenaan houden om uberhaupt te kunnen mogen inloggen.

Maar dan heb je dus nog steeds gebruikersauthenticatie nodig. Hoe je dat opzet (oath of een eigen systeem), mag je zelf weten

Het liefst wil ik niet het wiel opnieuw gaan uitvinden. Dus dan ga ik iets zoeken met Oauth ( laatste versie). Ik kon laatst ook wat PHP decrypt/encrypt updaten naar Openssl (dit omdat ik overging van php 5.6 naar php 7.2). Ik had al iets gelezen over Openssl i.c.m. Oauth, dacht ik. Of ik haal nu 2 dingen door elkaar.

EnnaN schreef op maandag 27 mei 2019 @ 20:04:
[...]
Dat is wat je wil. Neem een goeie Oauth2 library en implementeer die.
[...]

Okee! En dank voor je uitleg over de API key en de link die je hieronder geeft!

[ Voor 13% gewijzigd door Anoniem: 426269 op 27-05-2019 20:17 ]

[EnnaN]

the php league heeft er 1, geen ervaring mee, maar houdt zich aan psr standaarden, doet het voor een goeie zet aan versies... lijtke me prima keuze

https://github.com/thephpleague/oauth2-client

[Sebas1337]

Okee, moet ik dat dan zien als dat er in de user tabel naast het (auto)id, username en wachtwoord ook nog een veldje is met die lange, random string? En dat daar gewoon op gezocht wordt .i.p.v. de username en wachtwoord combi? De eerste keer bij inloggen moet ik het wel ergens tegenaan houden om uberhaupt te kunnen mogen inloggen.

Volgens mij stuur je een keer een username/password en dan wordt er een token gegenereerd die x tijd actief blijft. Vervolgens kun je elk request met dit token doen zonder opnieuw in te hoeven loggen. Totdat je te lang het token niet gebruikt hebt of deze verloopt.
Dus het is geen vaste string van x karakters, zou niet erg veilig zijn als deze onderschept zou worden...

[Barryvdh]

EnnaN schreef op maandag 27 mei 2019 @ 20:10:
the php league heeft er 1, geen ervaring mee, maar houdt zich aan psr standaarden, doet het voor een goeie zet aan versies... lijtke me prima keuze

https://github.com/thephpleague/oauth2-client

Als je zelf een API bouwt, wil je een Oauth2 server hebben ipv client, maar die hebben ze gelukkig ook
https://github.com/thephpleague/oauth2-server

[EnnaN]

Barryvdh schreef op maandag 27 mei 2019 @ 21:20:
[...]

Als je zelf een API bouwt, wil je een Oauth2 server hebben ipv client, maar die hebben ze gelukkig ook
https://github.com/thephpleague/oauth2-server

Ja, zeker!
Maar gezien ik angular/react las ging ik er zomaar van uit dat we het vooral over het bouwen van de client hadden, die moet er iig ook komen lijk tme?

[Xalephsis]

De server heb je nodig als je je eigen OAuth implementatie wilt aanbieden, de clients kun je gebruiken als je via de OAuth van derde partijen wil valideren, zoals GitHub, Google, Facebook en andere consorten.

Verder is een API stateless, dus moet je alles inderdaad ofwel lokaal opslaan ( localStorage, IndexedDB, CacheAPI ) of ook je state in sync houden op de API. Veel shops die via API werken slaan dingen ook vaak gewoon direct op de API kant op ( denk aan favorieten, winkelmandje etc )