it-swarm.com.de

Sollten wir accesstoken in unserer Datenbank für oauth2 speichern?

Ich muss die Facebook- und Google-Anmeldung in meiner Webanwendung implementieren. Ich muss auch auf die Facebook/Google + -Freundeliste eines Benutzers zugreifen. Ich habe die vollständige OAuth2-Dokumentation von Facebook und Google durchgesehen. Ich habe das Grundkonzept verstanden. Angenommen, für die Facebook-Anmeldung gelten folgende Schritte:

  1. Der Benutzer klickt auf die Schaltfläche "FB Login".
  2. Der Benutzer wird aufgefordert, sich bei Facebook anzumelden und die Erlaubnis zu erteilen. Wenn der Benutzer dies zulässt, wird ein Autorisierungscode zurückgegeben.
  3. Jetzt verwenden wir den Autorisierungscode, um ein Zugriffstoken zu erhalten.
  4. Wir können das Zugriffstoken in einer Sitzung speichern, um eine Benutzersitzung zu starten.
  5. Jetzt können wir das Zugriffstoken verwenden, um auf verschiedene Benutzerressourcen zuzugreifen.

Jetzt habe ich nach Schritt 3 einige Verwirrung. Sollten wir jedes Mal, wenn sich der Benutzer anmeldet oder das Zugriffstoken in unserer Datenbank speichert, ein Zugriffstoken generieren?

Wenn wir das Zugriffstoken in unserer Datenbank speichern, wie wir es wiederverwenden können, wenn ein Benutzer nach 10 Tagen auf unsere Website kommt (sagen wir, er hat die Browser-Cookies gelöscht) und erneut auf die Schaltfläche "FB-Anmeldung" klicken. Denn wenn der Benutzer erneut auf die Schaltfläche 'FB Login' klickt, erhält er einen neuen Autorisierungscode und muss den gesamten Vorgang erneut starten. Wie kann ich erkennen, dass dieser Benutzer bereits ein Zugriffstoken in meiner Datenbank hat?

Jede Hilfe wäre sehr dankbar.

90

Technisch gesehen können Sie das Zugriffstoken in Ihrer Datenbank speichern und für API-Aufrufe verwenden, bis es abläuft. Es könnte jedoch mehr Ärger als es wert ist.

Zum einen müssen Sie sich, wie Jonathan in seinem obigen Kommentar bemerkt, jetzt um die Sicherung Ihrer Datenbank und der darin enthaltenen Daten kümmern - diese Token ermöglichen den Zugriff auf einige recht privilegierte Informationen über Ihre Benutzer. Wenn Sie das Token einfach im Sitzungsspeicher speichern, wird es je nach Sitzungskonfiguration möglicherweise auch auf der Festplatte abgelegt. Es ist eine gute Idee, es verschlüsselt zu halten, während Sie es nicht verwenden.

Ihr vorgeschlagenes Szenario, in dem der Benutzer Cookies löscht und zurückkommt, ist ebenfalls ein Problem. Sie könnten das Zugriffstoken aus der Datenbank nehmen und es wieder in ihre Cookies einfügen, aber bevor Sie dies tun, müssen Sie sicherstellen, dass sie so sind, wie sie sagen, dass sie sind - und jetzt müssen Sie eine weitere Ebene von Passwörtern erstellen, um sie zu vergeben Zugriff auf das Token, das sie Ihnen bereits gegeben haben.

Sie sind wahrscheinlich besser dran, wenn Sie den Autorisierungsablauf einfach wiederholen, wenn sie zurückkommen und erneut auf die Anmeldeschaltfläche klicken. Es ist nicht das teuer. Aber wenn das wirklich ein Showstopper für Sie ist, ist das Speichern des Tokens eine Option. Sie müssen nur sehr vorsichtig sein, wenn Sie alle damit verbundenen Probleme lösen.

34
Bruce

Ich habe darüber nachgedacht und vielleicht eine Antwort gefunden, die für uns funktionieren wird, obwohl ich nicht sagen kann, ob es für Sie funktionieren würde.

In unserer Umgebung besteht der Hauptgrund für die Verwendung von Zugriffstoken möglicherweise darin, im Auftrag eines Benutzers zu arbeiten, nachdem ein automatisierter oder Backend-Prozess abgeschlossen wurde, oder nach einem Zeitplan. In einem solchen Szenario können wir den Benutzer nicht einfach auffordern, sich erneut anzumelden, da der Benutzer nicht direkt an diesem Workflow beteiligt ist (er hätte die Ausführung der Arbeit angefordert, ist aber nach Abschluss nicht vorhanden). Wir müssen also irgendwie Zugriff auf das Zugriffstoken haben.

Natürlich möchte ich die erneute Autorisierung überspringen, wo dies auch möglich ist, wenn dies keine Probleme verursacht.

Aber ich mag auch nicht die Idee, alles zu speichern, was zur Verwendung des Zugriffstokens auf dem Webserver erforderlich ist. Selbst wenn ich das Zugriffstoken in der Datenbank verschlüssele, beruhigt dies meine Befürchtungen nicht wirklich, wenn der Verschlüsselungsschlüssel auf dem Webserver gespeichert ist. Heck, das Client-Geheimnis und die App-ID sind auch da, das ist also alles.

Hier ist meine vorgeschlagene Lösung, für die vier Akteure erforderlich sind:

Der Webserver speichert die Appid-, Secret- und Datenbankverbindungszeichenfolge (natürlich). Wenn es ein App-Token erhält, generiert es einen zufälligen symmetrischen Verschlüsselungsschlüssel und verschlüsselt das Zugriffstoken. Die Datenbank erhält das verschlüsselte Zugriffstoken und der Verschlüsselungsschlüssel wird in einem Client-Cookie gespeichert. Gleichzeitig sendet der Webserver den Verschlüsselungsschlüssel und die Benutzer-ID paarweise an das Backend-System.

Wenn der Client die Site verwendet, kann eine erneute Authentifizierung vermieden werden, indem das Client-Cookie zum Entschlüsseln des Zugriffstokens in der Datenbank verwendet wird. Wenn der Cookie verschwindet, muss die erneute Authentifizierung erfolgen, egal was passiert. Das Backend-System (das eine viel kleinere Angriffsfläche als der Webserver hätte) verfügt auch über eine DB-Verbindungszeichenfolge. Daher ist dies der einzige Ort, an dem sich alle erforderlichen Informationen befinden, um mit Benutzerinformationen zu interagieren. Es könnte die Informationen nach Belieben für die Lebensdauer des Zugriffstokens verwenden.

Dadurch hat der Webserver nur vorübergehenden Zugriff auf ein Zugriffstoken, und das Token wird niemals auf dem Client gespeichert. Es scheint mir ziemlich sicher zu sein, obwohl einige vielleicht sagen würden, dass es überentwickelt ist. Gedanken?

13
Dominic P

Ich denke, es gibt einige Verwirrung über das Zugriffstoken und wie es verwendet wird, was ein Sicherheitsproblem verursachen kann.

Es ist richtig, dass die Token ein Sicherheitsrisiko darstellen können, dies hängt jedoch von den Informationen ab, die Sie vom Dienst anfordern. Eine Freundesliste enthält beispielsweise mehr Informationen als Vor- und Nachname. Diese Informationen sind jedoch nicht so wichtig wie persönliche Informationen. In beiden Fällen möchten Sie NIEMALS das tatsächliche Zugriffstoken verfügbar machen, da dies dem Offenlegen eines Kennworts für Ihre Anwendung gleicht.

Ich entscheide mich, wenn Sie so wollen, ein sekundäres "Token" zu erstellen, das einen Sitzungswert enthält (z. B. einen verschlüsselten Sitzungswert in Cookies), der den Benutzer identifiziert, bis er abläuft. Ich habe also das Zugriffstoken in der Datenbank (sollte wahrscheinlich verschlüsselt sein, um sicher zu gehen), das auf die Benutzerinformationen zugreifen kann.

Sie können die ID der Person auch über das Token abrufen. Wenn Sie dies mindestens in der Datenbank speichern, können Sie das abgerufene Token über die ID der Person abgleichen. Auf diese Weise können Sie beim Austausch eines Codes gegen das Zugriffstoken die IDs vergleichen und den richtigen Datensatz finden.

3
Mark

Viele dieser Antworten sind veraltet, da sie vor der weit verbreiteten Einführung von JSON Web Tokens (JWT) geschrieben wurden.

Sie sollten ein access_token so gut behandeln, als hätten Sie ein E-Mail/Passwort-Paar in der Hand, daher muss es sicher gespeichert und übertragen werden. Ein access_token sollte nicht zu viele Informationen enthalten, nur eine Benutzer-ID im Bereich sub eines JWT reicht aus. Da JWT böswillige Änderungen der Nutzdaten verhindert, können Sie die dort gespeicherte Bewilligung und ID sicher verwenden.

Das Speichern eines access_token auf einem Server kann für die meisten Anwendungen etwas schwierig sein, da Sie nur einen kurzen Ablauf für Ihre access_tokens verwenden und stattdessen ein refresh_token speichern können (weniger häufige DB-Aufrufe). Wenn Sie Benutzerinformationen benötigen, speichern Sie diese in einem ID-Token und verwenden Sie sie nur zum Anzeigen von Informationen über den authentifizierten Benutzer.

Fordern Sie das ID-Token erneut an, wenn Sie diese Informationen aktualisieren und NIEMALS ein id_token an eine API senden möchten.

Heutzutage implementieren intelligente Entwickler OpenID Connect, um ihre Benutzerinformationen und Zugriffszuschüsse zusätzlich zu OAuth 2.0) zu standardisieren, und ich würde dort beginnen, da die meisten Identify Providers (IdP) diese Spezifikation implementieren (z. B. Google, Facebook, Auth0, YourServiceHere).

1
SacWebDeveloper

Ich würde empfehlen, Token zu speichern, falls Sie jemals Ihre maximale Miete für Token in der von Ihnen verwendeten Anwendung erreichen könnten. Anstelle der Datenbank würde ich jedoch die Verwendung von Redis vorschlagen. Wenn ein Token verloren geht, sollte die App so eingerichtet sein, dass sie weiterhin ausgeführt werden kann, damit sie nicht langfristig bestehen bleibt. Redis ist viel schneller als die Verwendung der Datenbank. Es gibt auch einige wirklich einfache Redis-Implementierungen, die nicht lange dauern sollten Aufstehen und loslegen.

1
Dean Swiatek