Ich habe das Aktualisierungstoken in kurzer Zeit mehrmals zu Testzwecken verwendet, frage mich jedoch, ob Google-Aktualisierungstoken jemals ablaufen. Kann ich dasselbe Aktualisierungstoken verwenden, um über einen längeren Zeitraum (eine Woche oder sogar Monate) immer wieder ein anderes Zugriffstoken zu erhalten?
Antworten:
Der vom Google Auth-Server ausgegebene Aktualisierungstoken läuft nie ab - das ist der springende Punkt bei den Aktualisierungstoken. Das Aktualisierungstoken läuft ab (oder ich sollte sagen, dass es nicht autorisiert wird), wenn der Benutzer den Zugriff auf Ihre Anwendung widerruft.
In diesem Dokument wird die Funktion von Aktualisierungstoken klar angegeben.
Anstatt ein langlebiges Token auszugeben (normalerweise ein Jahr oder eine unbegrenzte Lebensdauer), kann der Server ein kurzlebiges Zugriffstoken und ein langlebiges Aktualisierungstoken ausstellen. Kurz gesagt, Sie können Aktualisierungstoken immer wieder verwenden, bis der Benutzer, der den Zugriff autorisiert hat, den Zugriff auf Ihre Anwendung widerruft.
Dies ist ein sehr verwirrender Thread. Die erste Antwort scheint richtig zu sein, zitiert aber eigentlich nichts Autorisierendes von Google.
Die definitivste Antwort, die ich gefunden habe, ist tatsächlich auf dem Spielplatz des Entwicklers, auf dem Sie den Token erhalten. In Schritt 2 befindet sich unten eine Notiz mit der Aufschrift:
"Hinweis: Auf dem OAuth-Spielplatz werden keine Aktualisierungstoken gespeichert. Da Aktualisierungstoken jedoch nie ablaufen, sollte der Benutzer die Seite für den autorisierten Zugriff auf das Google-Konto aufrufen, wenn er sie manuell widerrufen möchte."
Ich denke nicht, dass das ganz richtig ist:
Beachten Sie, dass die Anzahl der ausgegebenen Aktualisierungstoken begrenzt ist. Ein Limit pro Client / Benutzer-Kombination und ein weiteres pro Benutzer für alle Clients. Sie sollten Aktualisierungstoken im Langzeitspeicher speichern und weiter verwenden, solange sie gültig bleiben. Wenn Ihre Anwendung zu viele Aktualisierungstoken anfordert, kann dies zu Einschränkungen führen. In diesem Fall funktionieren ältere Aktualisierungstoken nicht mehr.
von dieser Seite: https://developers.google.com/youtube/v3/guides/authentication#installed-apps
Das stammt aus den youTube-Dokumenten (die ich als viel besser empfinde als andere API-Dokumente), aber ich denke, dass sie für alle Google Apps gleich sind.
Sieh dir das an:
Aktualisierungstoken sind gültig, bis der Benutzer den Zugriff widerruft. Dieses Feld ist nur vorhanden, wenn access_type = offline in der Autorisierungscode-Anforderung enthalten ist.
in https://developers.google.com/accounts/docs/OAuth2WebServer
Die Regeln haben sich irgendwann im Jahr 2017 geändert. Die beste Antwort ist meiner Meinung nach, dass dies vom Produkt abhängt. In der Google Mail-API läuft das Oauth 2.0-Aktualisierungstoken beispielsweise bei einer Kennwortänderung ab. Siehe diese https://support.google.com/a/answer/6328616?hl=de
Früher haben wir den API-Zugriff im Voraus eingerichtet und Aktualisierungstoken generiert, wenn wir NEUE Google Mail-Benutzer eingerichtet haben. Anschließend konnten wir ihre E-Mails archivieren (dies ist gesetzlich vorgeschrieben). Sobald sie jedoch ihr Kennwort ändern, wird das Aktualisierungstoken angezeigt wird widerrufen.
Vielleicht ist das Aktualisierungstoken für Youtube, Karten noch sehr langlebig, aber für Google Mail-API können Sie sich auf ein kurzes Token verlassen.
Das Hauptkonzept des Aktualisierungstokens ist, dass es langlebig ist und niemals abläuft.
Das Zugriffstoken hat eine Ablaufzeit und es läuft ab. Sobald es abgelaufen ist, können wir das Aktualisierungstoken abrufen, das immer wieder verwendet wird, bis der Benutzer von seinem Konto zurücktritt.
Lesen Sie dies unter: https://developers.google.com/identity/protocols/oauth2#expiration Sie müssen Ihren Code schreiben, um die Möglichkeit zu antizipieren, dass ein gewährtes Aktualisierungstoken möglicherweise nicht mehr funktioniert. Ein Aktualisierungstoken funktioniert möglicherweise aus einem der folgenden Gründe nicht mehr:
Der Benutzer hat den Zugriff Ihrer App widerrufen. Das Aktualisierungstoken wurde seit sechs Monaten nicht mehr verwendet. Der Benutzer hat die Kennwörter geändert und das Aktualisierungstoken enthält Google Mail-Bereiche. Das Benutzerkonto hat eine maximale Anzahl von gewährten (Live-) Aktualisierungstoken überschritten. Derzeit gibt es ein Limit von 50 Aktualisierungstoken pro Benutzerkonto und Client. Wenn das Limit erreicht ist, macht das Erstellen eines neuen Aktualisierungstokens das älteste Aktualisierungstoken automatisch ohne Warnung ungültig. Diese Begrenzung gilt nicht für Dienstkonten.
Es gibt auch eine größere Begrenzung für die Gesamtzahl der Aktualisierungstoken, die ein Benutzerkonto oder Dienstkonto auf allen Clients haben kann. Die meisten normalen Benutzer werden dieses Limit nicht überschreiten, das Testkonto eines Entwicklers jedoch möglicherweise.
Ich habe weitere Nachforschungen angestellt und es scheint, dass das Google-Zugriffstoken zum Abrufen eines Aktualisierungstokens während der ersten "Offline" -Anforderung verwendet wird. Ab diesem Zeitpunkt wird das Aktualisierungstoken verwendet, um ein neues Zugriffstoken auszugeben. Die Idee ist, dass ein Zugriffstoken ein kurzfristiges Token ist, das jedoch durch ein langfristiges Aktualisierungstoken erneuert werden kann. Dadurch entfällt die Notwendigkeit, die URL-Codevariable anzufordern, die einen Zwei-Endpunkt-Ansatz erfordert und mithilfe einer referrerbasierten Anforderung initiiert werden muss:
http://www.jensbits.com/2012/01/09/google-api-offline-access-using-oauth-2-0-refresh-token/
Einige REST-API-Dienste wie Dropbox stellen Zugriffstoken aus, die für immer gültig sind, aber Google stellt kurzfristige Zugriffstoken aus. PayPal verwendet einen Kompromiss, mit dem Zugriffstoken ohne Durchsetzung des URI-Referrers abgerufen werden können. Dies bedeutet, dass Zugriffstoken abgerufen werden können, ohne auf einen Link klicken zu müssen, um den Prozess zu starten. Aufgrund der Google-Methodik sollten API-Routinen nur nach Bedarf aufgerufen werden. Im Wesentlichen werden Anrufe über verweisbasierte Verfahren initiiert. Dies wird durch die Ausgabe von kurzlebigen Zugriffstoken oder Zugriffstoken gesteuert, die in einer Kette aktualisiert werden müssen. Dies erfordert, dass Entwickler genauer überlegen, wie ein System ablaufen soll.