Hallo,

ich habe vor, die Authentifikation für eine Webseite über einen OAuth 2 Provider abzuwickeln. Jetzt findet man zur grundlegenden Funktionsweise von OAuth 2 ja ausreichend Informationen und mir ist auch völlig klar, wie ich theoretisch zu Access / Refresh Tokens komme. Die helfen mir ja aber in erster Linie erstmal nur dazu weiter, im Namen des Resource Owners Requests an den OAuth Provider zu schicken.

Ich möchte das ganze aber in erster Linie als Ersatz für eine eigene Username/Passwort-Authentifikation einsetzen, und wie man das am besten anstellt, dazu konnte ich wirklich gar nichts finden. Speichere ich das Token in der Session des Users? Klingt eher blöd, dann müsste ich ja bei jedem Request das Token validieren, was einen weiteren Request zum OAuth Provider bedeuten würde. Genauso möchte ich verhindern, dass der User bei jedem neuen Besuch sichtbar über den OAuth Provider umgeleitet wird, wenn er die Autorisation schon einmal erteilt hat.

Und zu guter letzt, wie unterscheide ich eigentlich neue Benutzer (="Registrierung") und solche, die bereits "angemeldet" sind, BEVOR ich den Benutzer zum OAuth-Provider umleite?

Wer hat Erfahrung mit diesem Szenario und kann diese mit mir teilen? Alternativ wäre ich auch mit einer Quelle zu dieser Thematik zufrieden, wie gesagt konnte ich leider nichts dazu finden.

Viele Grüße

warum muss das token bei jedem weiteren request erneut validiert werden, wenn es in der session gespeichert ist? die session ist serverseitig. wenn kein risiko eines session-hijacking besteht, sollte das sicher sein.

Zitat von mjustin:

warum muss das token bei jedem weiteren request erneut validiert werden, wenn es in der session gespeichert ist? die session ist serverseitig. wenn kein risiko eines session-hijacking besteht, sollte das sicher sein.

Ich brauche ja nach wie vor einen Mechanismus, wie ich mir merken kann, ob ein Benutzer "eingeloggt" ist, sprich ein Cookie auf Clientseite. Was speichere ich in diesem Cookie? Das is tmir nicht ganz klar. Würde ich dort das Token speichern, dann müsste ich es ja validieren. Sonst würde ja jeder Angreifer, der dort einfach irgendeinen Wert hinterlegt, automatisch als eingeloggt gelten. So kann das also nicht funktionieren. Aber wie dann?

Zitat von Meflin:

Zitat von mjustin:

warum muss das token bei jedem weiteren request erneut validiert werden, wenn es in der session gespeichert ist? die session ist serverseitig. wenn kein risiko eines session-hijacking besteht, sollte das sicher sein.

Ich brauche ja nach wie vor einen Mechanismus, wie ich mir merken kann, ob ein Benutzer "eingeloggt" ist, sprich ein Cookie auf Clientseite. Was speichere ich in diesem Cookie? Das is tmir nicht ganz klar. Würde ich dort das Token speichern, dann müsste ich es ja validieren. Sonst würde ja jeder Angreifer, der dort einfach irgendeinen Wert hinterlegt, automatisch als eingeloggt gelten. So kann das also nicht funktionieren. Aber wie dann?

Prinzip der minimalen Datenspeicherung
Nur die Sessioon-Id ist als Cookie notwendig, der Client ist damit identifizierbar. Wenn die Session Id gültig ist, weiss der Server auch, ob die Session bereits authentifiziert wurde. Der Server hat ja ausser der Session Id beliebige Sessiondaten. Ein Boolean IsAuthenticated genügt.

Zitat von mjustin:

Nur die Session-Id ist als Cookie notwendig, der Client ist damit identifizierbar.

Ja, mir erschien das immer als zu einfach angreifbar (eine Session ID zufällig zu treffen sollte nahezu unmöglich gemacht werden und es reicht ja nach wie vor das Cookie zu stehlen, um die Authentizität zu übernehmen - was man aber wohl nicht verhindern kann). Aber das scheint ja so durchaus Best Practice zu sein

Also speichere ich mir in einer Tabelle zu jedem Benutzer Auth Token + Refresh Token + Expiration Date. Bei erfolgtem Login speichere ich in einer Session Tabelle die UserId / Session Id. Und wenn ein wiederkehrender Besucher kein gültiges Access Token mehr hat, führe ich im Hintergrund den Refresh aus.

Zitat von Meflin:

Zitat von mjustin:

Nur die Session-Id ist als Cookie notwendig, der Client ist damit identifizierbar.

Ja, mir erschien das immer als zu einfach angreifbar (eine Session ID zufällig zu treffen sollte nahezu unmöglich gemacht werden und es reicht ja nach wie vor das Cookie zu stehlen, um die Authentizität zu übernehmen - was man aber wohl nicht verhindern kann)

Das Risiko kann man falls notwendig mit HTTPS schon deutlich senken.
Ich überlege auch in meinem Webframework OpenId oder Oauth zu unterstutzen, habe mich aber mit der Suche nach Delphi/Free Pascal Libraries bisher noch zurückgehalten.
Happy Coding!