Użyłem tokena odświeżania kilka razy w krótkim okresie do celów testowych, ale zastanawiam się, czy tokeny odświeżania Google kiedykolwiek wygasają? Czy mogę użyć tego samego tokena odświeżania, aby wielokrotnie otrzymywać kolejny token dostępu przez długi okres (tydzień lub nawet miesiące)?
Odpowiedzi:
Wydane przez serwer Google Auth tokeny odświeżania nigdy nie tracą ważności - o to właśnie chodzi w tokenach odświeżania. Token odświeżania wygaśnie (lub powinienem powiedzieć, że stanie się nieautoryzowany), gdy użytkownik cofnie dostęp do twojej aplikacji.
Zapoznaj się z tym dokumentem, w którym jasno określono funkcję tokenów odświeżania.
Zamiast wydawać długotrwały token (zazwyczaj ważny przez rok lub nieograniczony okres eksploatacji), serwer może wystawić krótkotrwały token dostępu i długotrwały token odświeżania. Krótko mówiąc, możesz wielokrotnie używać tokenów odświeżania, dopóki użytkownik, który autoryzował dostęp, nie cofnie dostępu do Twojej aplikacji.
To bardzo zagmatwany wątek. Pierwsza odpowiedź wydaje się być poprawna, ale tak naprawdę nie cytuje niczego autorytatywnego z Google.
Najbardziej ostateczna odpowiedź, jaką znalazłem, znajduje się na placu zabaw dewelopera, gdzie uzyskujesz token. Krok 2 ma na dole notatkę, która mówi:
„Uwaga: OAuth Playground nie przechowuje tokenów odświeżania, ale ponieważ tokeny odświeżania nigdy nie wygasają, użytkownik powinien przejść do strony autoryzowanego dostępu do konta Google, jeśli chce je ręcznie unieważnić”.
Nie sądzę, żeby to była do końca prawda:
Zwróć uwagę, że istnieją ograniczenia liczby tokenów odświeżania, które zostaną wydane; jeden limit na kombinację klienta / użytkownika i inny na użytkownika dla wszystkich klientów. Należy zapisać tokeny odświeżania w długoterminowym magazynie i nadal z nich korzystać, dopóki pozostają ważne. Jeśli aplikacja zażąda zbyt wielu tokenów odświeżania, może napotkać te limity, w którym to przypadku starsze tokeny odświeżania przestaną działać.
z tej strony: https://developers.google.com/youtube/v3/guides/authentication#installed-apps
To pochodzi z dokumentów YouTube (które uważam za znacznie lepsze niż inne dokumenty API), ale myślę, że jest tak samo we wszystkich aplikacjach Google.
Zobacz:
Tokeny odświeżania są ważne, dopóki użytkownik nie cofnie dostępu. To pole jest obecne tylko wtedy, gdy access_type = offline jest uwzględnione w żądaniu kodu autoryzacji.
w https://developers.google.com/accounts/docs/OAuth2WebServer
Zasady uległy zmianie gdzieś w 2017 roku, więc myślę, że najlepszą odpowiedzią jest to, że zależy to od produktu. Na przykład w interfejsie Gmail API token odświeżania Oauth 2.0 wygasa po zmianie hasła. Zobacz https://support.google.com/a/answer/6328616?hl=en
Kiedyś konfigurowaliśmy dostęp do API z wyprzedzeniem i generowaliśmy tokeny odświeżania, kiedy konfigurowaliśmy NOWYCH użytkowników Gmaila, a potem mogliśmy archiwizować ich pocztę (jesteśmy do tego zobowiązani przez prawo), ale teraz, gdy tylko zmienią hasło, odśwież token jest unieważniony.
Być może w przypadku youtube, map, token odświeżania jest nadal naprawdę długowieczny, ale w przypadku interfejsu API Gmaila można liczyć na krótki token.
Główną koncepcją odświeżającego tokena jest to, że jest długotrwały i nigdy nie wygasa.
Token dostępu ma czas wygaśnięcia i wygasa, po wygaśnięciu możemy przejść po token odświeżania, który będzie używany wielokrotnie, dopóki użytkownik nie odwoła się ze swojego konta.
Przeczytaj to z: https://developers.google.com/identity/protocols/oauth2#expiration Musisz napisać swój kod, aby przewidzieć możliwość, że przyznany token odświeżania może przestać działać. Token odświeżania może przestać działać z jednego z następujących powodów:
Użytkownik unieważnił dostęp Twojej aplikacji. Token odświeżania nie był używany przez sześć miesięcy. Użytkownik zmienił hasła, a token odświeżania zawiera zakresy Gmaila. Konto użytkownika przekroczyło maksymalną liczbę przyznanych (aktywnych) tokenów odświeżania. Obecnie istnieje limit 50 tokenów odświeżania na konto użytkownika na klienta. Jeśli limit zostanie osiągnięty, utworzenie nowego tokena odświeżania automatycznie unieważnia najstarszy token odświeżania bez ostrzeżenia. Ten limit nie dotyczy kont usług.
Istnieje również większy limit całkowitej liczby tokenów odświeżania, które konto użytkownika lub konto usługi może mieć na wszystkich klientach. Większość zwykłych użytkowników nie przekroczy tego limitu, ale konto testowe programisty może.
Zrobiłem dalsze badania i wydaje się, że token dostępu Google jest używany do pobierania tokena odświeżania podczas pierwszego żądania „offline”. Od tego momentu token odświeżania jest używany do wystawiania nowego tokenu dostępu. Chodzi o to, że token dostępu jest tokenem krótkoterminowym, ale można go odnowić za pomocą tokenu długoterminowego odświeżania. Eliminuje to konieczność żądania zmiennej „kod” adresu URL, która wymaga podejścia z dwoma punktami końcowymi i musi zostać zainicjowana przy użyciu żądania opartego na stronie odsyłającej:
http://www.jensbits.com/2012/01/09/google-api-offline-access-using-oauth-2-0-refresh-token/
Niektóre usługi REST API, takie jak Dropbox, wydają tokeny dostępu, które są wieczne, ale Google wydaje tokeny dostępu krótkoterminowego. PayPal używa kompromisu, dzięki czemu umożliwia pobieranie tokenów dostępu bez wymuszania odsyłacza URI. Oznacza to, że tokeny dostępu można odzyskać bez konieczności klikania łącza w celu zainicjowania procesu. Metodologia Google oznacza, że procedury API powinny być wywoływane tylko wtedy, gdy są potrzebne. Zasadniczo połączenia są inicjowane za pomocą procedur opartych na odsyłaczach. Jest to kontrolowane przez wydawanie krótkotrwałych tokenów dostępu lub tokenów dostępu, które muszą być odświeżane w łańcuchu. Wymaga to od programistów dokładniejszego przemyślenia sposobu, w jaki powinien działać system.