Почему Google OAuth2 запрашивает у пользователя разрешение, когда я снова отправляю их на auth url

Со старым google openid, когда я отправил пользователя (который ранее подключился к моему приложению) к URL-адресу auth, он немедленно перенаправит их обратно в мое приложение.

Теперь, с OAuth2, auth url продолжает запрашивать у пользователя разрешение. Я прочитал некоторые документы по этому вопросу, но я не понимаю, как этот поток должен работать:

Пользователь регистрируется в Google через мое приложение и клики ALLOW для разрешений
Через несколько дней cookie очищается, пользователь возвращается на мой сайт, нажимает "Войти в Google".
Пользователь не запрашивает разрешения снова, и они немедленно вошли в систему.

Я думаю, что это имеет какое-то отношение к сохранению токена аутентификации или обновлению токена на шаге 1, но на шаге 3 я не знаю, кто они, поэтому как я могу сопоставить их с соответствующим токеном аутентификации или обновления, чтобы получить действительный токен доступа.

В моих тестах, когда я отправляю их на исходный URL-адрес auth на шаге 1, они снова запрашивают разрешения.

РЕДАКТИРОВАТЬ: Найден решение

Google-api по умолчанию ставит "assert_prompt = force" при создании URL-адреса auth.

Ответ 1

Да, как вы отметили, с помощью параметра authorized_prompt = force URL будет принудительно показывать пользователю диалог auth каждый раз. Просто удалив этот URL-адрес, пользователь не будет запрашивать последующие потоки аутентификации.

Существует небольшая разница в ответе, который вы получите, если используете поток на стороне сервера (response_type = code) и автономный доступ (access_type = offline). В первый раз, когда пользователь разрешает вам (когда он видит экран утверждения), или если вы вынуждаете это с помощью assert_prompt = force, то при обмене кодом auth вам будет предоставлен refresh_token и access_token.

Однако каждый раз, когда пользователь не отображается с экраном утверждения (последующий аут, когда он не использует assert_prompt = force), при обмене кодом auth вам будет предоставлен только доступ_отказ, нет refresh_token. Поэтому, если этот поток вы используете, и если вы хотите иметь доступ к данным пользователя в автономном режиме, вам нужно убедиться, что вы сохраните refresh_token локально для дальнейшего использования, когда вы его получите в первый раз. Это может произойти только в том случае, если вы запрашиваете доступ к другим типам данных, чем просто данные auth, хотя (используя поток OAuth 2 вы можете запросить доступ к другим данным, например, данные API контактов, данные API календаря, данные о драйвере и т.д....), как правило, для обычного потока Open ID не требуется автономный доступ.

Ответ 2

Просто передача дополнительного параметра в запросе 'approval_prompt=auto' работала для меня.

Ответ 3

Для меня это был параметр hd (размещенный домен). После удаления с авторизационного url мне был предоставлен список пользователей для Auth. Подробнее о параметре hd здесь https://developers.google.com/identity/protocols/OpenIDConnect#hd-param

Ответ 4

Небольшое обновление, эта ссылка может помочь: https://github.com/googleapis/oauth2client/issues/453

"запрос на утверждение" был заменен на "запрос" с параметрами: "нет", "согласие" и "выбор_аккаунта"