[ PHP ] SaaS applicatie login over meerdere domeinen

[RickyHeijnen]

Ik heb een SaaS applicatie dat op meerdere domeinen beschikbaar kan zijn. Nu wil ik als ze wisselen van domein dat ze toch ingelogd blijven binnen de applicatie. Ik zal dus bij het linken naar een ander domein iets moeten meegeven waardoor de gebruiker herkend wordt.

Mijn idee is om een user_sessions tabel te maken en iedere gebruiker na inloggen een eigen session ID te geven en die op te slaan in de db + als cookie te plaatsen. Elke keer als ik link naar een extern domein doe ik dit bijv naar external.php?l=https://domain.tld/bla/bla/bla . Het script op external.php maakt een random token aan, slaat die op in users_sessions_tokens en geef die mee aan de link https://domain.tld/bla/bla/bla?token=xxxxxxxx . Hiermee kan ik zien welke user bij deze token hoort en diezelfde session ID nu ook als cookie op dit domein plaatsen.

Is dit een beetje een logische denkwijze? Of zie ik bijv qua security iets over het hoofd?

[kwaakvaak_v2]

Je bedoeld dat je liever een eigen gemaakte versie van authenticatie wilt maken in plaats van gebruik te maken van iets als https://oauth2.thephpleague.com/ al dan niet aangevuld met openID?

Zeker met dingen als security is het vaak veel verstandiger om naar bestaande en goed geteste systemen te kijken

[RobIII]

RickyHeijnen schreef op donderdag 25 april 2019 @ 16:46:
Of zie ik bijv qua security iets over het hoofd?

Nogal ja. Je hebt nu in je browserhistory een session ID staan. Handig als ik in de bieb kom en daar je site in de historie vind. Kan ik zo een sessie overnemen van een willekeurig iemand. En dan heb ik 't nog niet gehad over gebruikers die links copy/pasten op willekeurige sites/fora en daarmee potentieel hun sessie weggeven zonder dat ze 't beseffen. Dit is een heel, héél slecht idee. Sorry.

Je moet beseffen dat die token letterlijk toegang geeft tot iemands sessie, net zoals een sessionid dat doet. Sterker: heel dat token-gedoe is eigenlijk alleen maar een omweg; je had net zo goed 't sessie-id in de url kunnen mikken. Je zou zo'n token natuurlijk (i.t.t. een sessie) maar eenmalig kunnen gebruiken, kunnen laten verlopen enzovoorts, maar onder de streep is zoiets in een URL zetten vragen om problemen.

[ Voor 28% gewijzigd door RobIII op 25-04-2019 18:00 ]

[RickyHeijnen]

kwaakvaak_v2 schreef op donderdag 25 april 2019 @ 16:52:
Je bedoeld dat je liever een eigen gemaakte versie van authenticatie wilt maken in plaats van gebruik te maken van iets als https://oauth2.thephpleague.com/ al dan niet aangevuld met openID?

Absoluut niet! Mijn voorkeur gaat zeker uit naar het gebruiken bestaande technieken. Maar ik moet me dan nog maar even wat verdiepen in oAuth2 en openID, want in mijn gedachten is dat meer een techniek om op andere websites in te loggen zoals "login with facebook" of "login with google" knoppen.

RobIII schreef op donderdag 25 april 2019 @ 17:56:
[...]

Nogal ja. Je hebt nu in je browserhistory een session ID staan. Handig als ik in de bieb kom en daar je site in de historie vind. Kan ik zo een sessie overnemen van een willekeurig iemand. En dan heb ik 't nog niet gehad over gebruikers die links copy/pasten op willekeurige sites/fora en daarmee potentieel hun sessie weggeven zonder dat ze 't beseffen. Dit is een heel, héél slecht idee. Sorry.

Sorry ik had moeten vermelden dat de token die in de URL meegegeven wordt natuurlijk wel wordt verwijderd in de database. Dus die werkt maar eenmalig, daarom zet ik ook direct die sessionid cookie.
Maar ik had zelf ook al het idee dat ik misschien iets te simpel zat te denken.

Ik ga eens duiken in oAuth2 en openID om te zien wat ik daarvan kan gebruiken.

[johnkeates]

Je zal iets met SSO moeten doen en dan bijv. een JWT zodat je niet tussen je verschillende tenants state hoeft te delen. Zoals aangehaald OAuth2 of OpenID.

[ Voor 12% gewijzigd door johnkeates op 25-04-2019 21:29 ]

[Voutloos]

Sowieso kan je inderdaad met genoemde termen eerst wat theorie op doen. Dit qua security goed krijgen doe je niet zomaar.

'Iets bouwen' dat een beetje werkt in de ideale wereld is helemaal zo moeilijk niet, dus door dit topic '[php]' te noemen en wat technische basics over een database en een token te noemen lijk je de focus niet op de echt lastige zaken te hebben.

Als je eenmaal weet wat je wil, met rechten, state (JWT kan zeker, maar denk dan wel na hoe je snel overal kan uitloggen of account kan disablen etc etc), werking HTTP/cookies/etc en security zaken als CORS, session fixation, replay attacks, etc etc is het schrijven van de code het probleem niet meer. Kan overigens prima met o.a. PHP (en neem aub bestaande libs mee), maar het is gewoon geen PHP of überhaupt code vraag.

Als ik heel eerlijk ben; je zat met [PHP] Session wordt overgenomen door andere user en op basis van dat topic denk ik dat je een half jaartje later nog wel wat begeleiding of een collega kan gebruiken.