При условии, что у меня есть приложение Google, пользователь авторизовал мое приложение с помощью OAuth2 много раз, и мое приложение хранило все обновленные токены, созданные с помощью авторизации. сколько действительных токенов обновления можно сохранить в моем приложении? и сколько действительных токенов доступа, сгенерированных каждым токеном обновления?Сколько токенов обновления и токенов доступа могут иметь один клиент одновременно для Google?
В настоящее время я работаю с другими API, использующими OAuth2, и всякий раз, когда пользователь разрешает вашему приложению получать информацию, старые токены становятся недействительными. В моем случае, если пользователь повторно авторизует, я бросаю старые жетоны и вставляю новые. Маркер доступа может и в большинстве случаев иметь ограниченный срок службы. Если токен доступа истёк, вы получите сообщение об ошибке, и вам нужно будет запросить новый токен доступа с помощью refreshtoken. В некоторых случаях вы также получите новый токен обновления для вашего токена доступа, чтобы запросить следующий accesstoken. См. https://developers.google.com/identity/protocols/OAuth2 для информации, относящейся к Google.
Как насчет того, чтобы один пользователь разрешил много токенов в моем приложении, и я использую их все для различного использования? сколько действительного токена обновления я могу удержать. – Atvoid
С OAuth2 клиентский идентификатор будет иметь только 1 активный набор токенов (доступ + обновление). Если у вас несколько идентификаторов ClientID из API, вы можете определить разные области, но тогда пользователю придется авторизовать со всеми различными приложениями (ваши идентификаторы клиента), и я предполагаю, что это не ваш прецедент. Традиционно у вас будет токен доступа с ограниченным сроком службы и токен обновления, чтобы получить новый токен доступа. Объем вашего приложения, так как он был разрешен пользователем, связан с вашим идентификатором ClientID. Если пользователь повторно авторизует ваше приложение, старые токены станут недействительными. – martwetzels
@martwetzels Это не похоже на 100% правду, хотя это зависит от интерпретации. Я пытался найти ответ для этого, и все, что я могу догадаться, заключается в том, что когда клиент (а не clientId) получает новый refresh_token, он ДОЛЖЕН отказаться от старого. Однако RFC только говорит, что сервер МОЖЕТ отменить старый токен обновления, а не ДОЛЖЕН. Поэтому, если клиент поделился предыдущей командой client_id/access_token/refresh_token с другим клиентом, он сможет использовать тот же client_id, но другой access_token/refresh_token комбо. Все зависит от того, отменил ли сервер старый ... – fimbulvetr