it-swarm.com.de

Wo soll ich OAuth2-Zugriffstoken speichern?

Ich erstelle ein REST API-Backend für eine mobile Anwendung. Bei unserer Entwurfsauswahl haben wir beschlossen, OAuth2-Anbieter die Anmeldesicherheit übernehmen zu lassen.

Ich bin mir jedoch nicht sicher, was die beste Vorgehensweise für das Zugriffstoken ist, das ich von den OAuth2-Anbietern erhalte.

Die Situation ist, dass ich vom OAuth2-Anbieter ein Zugriffstoken erhalte, wenn der Benutzer sich anmeldet. Ich muss dieses Token jedes Mal verwenden, wenn die mobile Anwendung eine Anfrage an mein Back-End sendet. So kann ich mich gegen den OAuth2-Anbieter validieren, um festzustellen, ob das Token noch gültig ist.

Ich weiß, dass ich ein JWT erstellen und es der mobilen Anwendung übergeben werde, die es jedes Mal verwendet, wenn es eine Anfrage stellt.

Meine Frage ist nun, ob ich das Zugriffstoken, das ich vom OAuth2-Anbieter erhalten habe, als Ansprüche im JWT speichern soll.
Oder sollte ich es in einer Datenbank speichern und mit der Benutzer-ID verbinden, die ich in den JWT-Ansprüchen speichern werde?

Vielleicht wird empfohlen, das JWT mit JWE zu verschlüsseln? Wenn dies der Fall ist, verringert sich die Leistung stärker, wenn ich für jede Anforderung entschlüssele, anstatt eine Datenbanksuche durchzuführen (ich verwende entweder MongoDB oder Redis), oder sind die Auswirkungen auf die Leistung gleich?

Die Verbindung zu meiner REST API) erfolgt über HTTPS.

18
Daniel

Wenn die Anforderung an die Drittanbieter-API über Ihren Server erfolgt, speichern Sie das Zugriffstoken in der mit dem Benutzer verknüpften Datenbank, verschlüsselt mit einem Schlüssel, der als Umgebungsvariable gespeichert ist. Wenn die Datenbank kompromittiert ist, sind die Token sicher. (Bonus, verschlüsseln Sie die Token mit einem Schlüssel, der in der mobilen App generiert und gespeichert wird.)

Wenn die Anforderung an die Drittanbieter-API direkt von der mobilen App stammt, speichern Sie das Zugriffstoken auf dem Telefon, verschlüsselt mit einem eindeutigen Schlüssel für jeden Benutzer, der in der Datenbank Ihres Servers gespeichert ist. Die dezentrale Speicherung vertraulicher Informationen ist sicherer als die zentralisierte Speicherung (Unterteilung). Wenn das Telefon gestohlen wird, muss es bei Ihrem Server authentifiziert werden, bevor der Entschlüsselungsschlüssel abgerufen werden kann. Wenn Ihr Server kompromittiert ist, sind die Token nicht vorhanden.

Ich habe JWT nicht verwendet.

10
Chloe

Zugriffstoken sind laut RFC angeblich eingeschränkter Zugriff. Anstatt sich Gedanken darüber zu machen, wo etwas von hohem Wert gespeichert werden soll, wo der Server möglicherweise gefährdet ist, ist es besser, die Dauer des Zugriffs auf das Token einfach zu begrenzen.

Dies ist im RFC speziell für Inhaber-Token festgelegt:

Kurzlebige Inhaber-Token ausgeben: Tokenserver sollten kurzlebige Träger-Token (eine Stunde oder weniger) ausgeben, insbesondere wenn Token an Clients ausgegeben werden, die in einem Webbrowser oder in anderen Umgebungen ausgeführt werden, in denen Informationslecks auftreten können. Die Verwendung kurzlebiger Trägermarken kann die Auswirkung von Leckagen verringern.

2
Steve Sether