Ich fange gerade erst an, mit Google API und OAuth2 zu arbeiten. Wenn der Client meine App autorisiert, erhalte ich ein "Aktualisierungstoken" und ein kurzlebiges "Zugriffstoken". Jedes Mal, wenn das Zugriffstoken abläuft, kann ich mein Aktualisierungstoken an Google senden, und sie geben mir ein neues Zugriffstoken.

Meine Frage ist, wozu das Zugriffstoken abläuft. Warum kann es nicht einfach ein dauerhaftes Zugriffstoken anstelle des Aktualisierungstokens geben?

Läuft das Aktualisierungstoken auch ab?

Weitere Informationen zum Google OAuth2-Workflow finden Sie unter Verwenden von OAuth 2.0 für den Zugriff auf Google APIs .

Dies ist sehr implementierungsspezifisch, aber die allgemeine Idee besteht darin, Anbietern die Möglichkeit zu geben, kurzfristige Zugriffstoken mit langfristigen Aktualisierungstoken auszugeben. Warum?

• Viele Anbieter unterstützen Inhaber-Token, die in Bezug auf die Sicherheit sehr schwach sind. Indem sie kurzlebig sind und aktualisiert werden müssen, begrenzen sie die Zeit, in der ein Angreifer einen gestohlenen Token missbrauchen kann.
• Bei der Bereitstellung in großem Maßstab möchte nicht bei jedem API-Aufruf eine Datenbanksuche durchgeführt werden. Stattdessen wird ein selbstcodiertes Zugriffstoken ausgegeben, das durch Entschlüsselung überprüft werden kann. Dies bedeutet jedoch auch, dass es keine Möglichkeit gibt, diese Token zu widerrufen, sodass sie für kurze Zeit ausgegeben werden und aktualisiert werden müssen.
• Das Aktualisierungstoken erfordert eine Clientauthentifizierung, wodurch es stärker wird. Im Gegensatz zu den oben genannten Zugriffstoken wird es normalerweise mit einer Datenbanksuche implementiert.

Einige Szenarien können dazu beitragen, den Zweck des Zugriffs und der Aktualisierung von Token sowie die technischen Kompromisse beim Entwurf eines oauth2-Systems (oder eines anderen Auth-Systems) zu veranschaulichen:

Web-App-Szenario

Im Web-App-Szenario haben Sie mehrere Optionen:

1. Wenn Sie über eine eigene Sitzungsverwaltung verfügen, speichern Sie sowohl das access_token als auch das refresh_token für Ihre Sitzungs-ID im Sitzungsstatus Ihres Sitzungsstatusdienstes. Wenn der Benutzer eine Seite anfordert, für die Sie auf die Ressource zugreifen müssen, verwenden Sie das access_token. Wenn das access_token abgelaufen ist, verwenden Sie das refresh_token, um das neue abzurufen.

Stellen wir uns vor, jemand schafft es, Ihre Sitzung zu entführen. Sie können nur Ihre Seiten anfordern.

2. Wenn Sie keine Sitzungsverwaltung haben, setzen Sie das access_token in ein Cookie und verwenden Sie es als Sitzung. Wenn der Benutzer dann Seiten von Ihrem Webserver anfordert, senden Sie das access_token. Ihr App-Server kann das access_token bei Bedarf aktualisieren.

Vergleich von 1 und 2:

In 1 werden access_token und refresh_token nur auf dem Weg zwischen dem Autorisierungsserver (in Ihrem Fall Google) und Ihrem App-Server über das Kabel übertragen. Dies würde auf einem sicheren Kanal erfolgen. Ein Hacker könnte die Sitzung entführen, aber nur mit Ihrer Web-App interagieren. In 2 könnte der Hacker das access_token entfernen und eigene Anforderungen an die Ressourcen stellen, auf die der Benutzer Zugriff gewährt hat. Selbst wenn der Hacker das access_token erhält, hat er nur ein kurzes Fenster, in dem er auf die Ressourcen zugreifen kann.

In beiden Fällen sind refresh_token und clientid / secret nur dem Server bekannt, sodass der Webbrowser keinen langfristigen Zugriff erhalten kann.

Stellen Sie sich vor, Sie implementieren oauth2 und legen eine lange Zeitüberschreitung für das Zugriffstoken fest:

In 1) Es gibt hier keinen großen Unterschied zwischen einem kurzen und einem langen Zugriffstoken, da es im App-Server versteckt ist. In 2) könnte jemand das access_token im Browser abrufen und es dann verwenden, um lange Zeit direkt auf die Ressourcen des Benutzers zuzugreifen.

Mobiles Szenario

Auf dem Handy gibt es einige Szenarien, die ich kenne:

1. Speichern Sie die Client-ID / das Geheimnis auf dem Gerät und lassen Sie das Gerät orchestrieren, um Zugriff auf die Ressourcen des Benutzers zu erhalten.

2. Verwenden Sie einen Backend-App-Server, um die Client-ID / das Geheimnis geheim zu halten und die Orchestrierung durchführen zu lassen. Verwenden Sie das access_token als eine Art Sitzungsschlüssel und übergeben Sie es zwischen dem Client und dem App-Server.

1 und 2 vergleichen

In 1) Sobald Sie clientid / secret auf dem Gerät haben, sind sie nicht mehr geheim. Jeder kann dekompilieren und dann so tun, als ob er Sie wäre, natürlich mit Erlaubnis des Benutzers. Das access_token und das refresh_token befinden sich ebenfalls im Speicher und können auf einem gefährdeten Gerät aufgerufen werden. Dies bedeutet, dass jemand als Ihre App fungieren kann, ohne dass der Benutzer seine Anmeldeinformationen angibt. In diesem Szenario hat die Länge des access_token keinen Einfluss auf die Hackbarkeit, da sich refresh_token an derselben Stelle wie access_token befindet. In 2) werden die Client-ID / das Geheimnis oder das Aktualisierungstoken kompromittiert. Hier bestimmt die Länge des Ablaufs von access_token, wie lange ein Hacker auf die Ressourcen des Benutzers zugreifen kann, falls er darauf zugreifen kann.

Verfallslängen

Hier hängt es davon ab, was Sie mit Ihrem Authentifizierungssystem sichern, wie lange Ihr access_token-Ablauf dauern soll. Wenn es für den Benutzer besonders wertvoll ist, sollte es kurz sein. Etwas weniger Wertvolles, es kann länger sein.

Einige Leute wie Google verfallen das refresh_token nicht. Manche mögen Stackflow. Die Entscheidung über den Ablauf ist ein Kompromiss zwischen Benutzerfreundlichkeit und Sicherheit. Die Länge des Aktualisierungstokens hängt von der Länge der Benutzerrückgabe ab, dh legen Sie die Aktualisierung so fest, wie oft der Benutzer zu Ihrer App zurückkehrt. Wenn das Aktualisierungstoken nicht abläuft, wird es nur mit einem expliziten Widerruf widerrufen. Normalerweise wird eine Anmeldung nicht widerrufen.

Hoffe, dass ziemlich lange Post nützlich ist.

Zusätzlich zu den anderen Antworten:

Einmal erhalten, werden Zugriffstoken normalerweise zusammen mit jeder Anforderung von Clients an geschützte Ressourcenserver gesendet. Dies birgt ein Risiko für das Stehlen und Wiedergeben von Zugriffstoken (vorausgesetzt natürlich, dass Zugriffstoken vom Typ "Träger" sind (wie im ursprünglichen RFC6750 definiert).

Beispiele für diese Risiken im wirklichen Leben:

• Ressourcenserver sind im Allgemeinen verteilte Anwendungsserver und weisen im Vergleich zu Autorisierungsservern normalerweise niedrigere Sicherheitsstufen auf (niedrigere SSL / TLS-Konfiguration, weniger Härtung usw.). Autorisierungsserver hingegen werden normalerweise als kritische Sicherheitsinfrastruktur betrachtet und unterliegen einer stärkeren Verhärtung.

• Zugriffstoken werden möglicherweise in HTTP-Traces, -Protokollen usw. angezeigt, die zu Diagnosezwecken auf den Ressourcenservern oder Clients legitim erfasst werden. Diese Spuren können über öffentliche oder halböffentliche Orte (Bug-Tracer, Service-Desk usw.) ausgetauscht werden.

• Backend-RS-Anwendungen können an mehr oder weniger vertrauenswürdige Dritte ausgelagert werden.

Das Aktualisierungstoken wird dagegen normalerweise nur übertragen zweimal über die Kabel und immer zwischen dem Client und dem Autorisierungsserver übertragen: einmal, wenn es vom Client abgerufen wird, und einmal, wenn es vom Client während der Aktualisierung verwendet wird (wobei die vorherige Aktualisierung effektiv "abläuft") Zeichen). Dies ist eine drastisch begrenzte Möglichkeit zum Abfangen und Wiedergeben.

Letzter Gedanke: Aktualisierungstoken bieten, wenn überhaupt, nur sehr wenig Schutz vor kompromittierten Clients.

Es ist im Wesentlichen eine Sicherheitsmaßnahme. Wenn Ihre App kompromittiert ist, hat der Angreifer nur Zugriff auf das kurzlebige Zugriffstoken und keine Möglichkeit, ein neues zu generieren.

Aktualisierungstoken verfallen ebenfalls, sie sollten jedoch viel länger als das Zugriffstoken leben.