Google OAuth 2.0: Refre sh access_token и New refresh_token - PullRequest
Новая
       18

Google OAuth 2.0: Refre sh access_token и New refresh_token

0 голосов
/ 04 февраля 2020

Проблема

Я озадачен, когда обновление access_token с ранее полученным refresh_token не возвращает новое refresh_token.

Google OAuth 2.0 Шаги

Запрос authentication_code

Следующий URL, открытый в браузере по умолчанию, запрашивает код аутентификации, с access_type=offline для возврата refresh_token применение возвращенного кода для получения access_token: 

https://accounts.google.com/o/oauth2/v2/auth?
access_type=offline
&prompt=consent
&response_type=code
&client_id=[** CLIENT_ID **]
&redirect_uri=http://localhost
&state=[** STATE **]
&scope=https%3a%2f%2fwww.googleapis.com%2fauth%2fuserinfo.email%20https%3a%2f%2fwww.googleapis.com%2fauth%2fuserinfo.profile%20https%3a%2f%2fwww.googleapis.com%2fauth%2fdrive

Parse redirect_uri для authentication_code

Свойства строки запроса возвращенных redirect_uri=http://localhost анализируются следующим образом: 

{
  "state": "[** STATE **]",
  "code": "[** AUTH CODE **]",
  "scope": "email profile https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/drive openid",
  "authuser": "1",
  "hd": "[** HOST DOMAIN **]",
  "prompt": "consent",
  "session_state": "[** SESSION STATE **]"
}

Запрос access_token с использованием authentication_code

Используя возвращенное значение [** AUTH CODE **], запрос access_token и refresh_token: 

curl "https://www.googleapis.com/oauth2/v4/token" \
--request POST \
--silent \
--data 'grant_type=authorization_code
  &code=[** AUTH CODE **]
  &client_id=[** CLIENT_ID **]
  &client_secret=[** CLIENT_SECRET **]
  &redirect_uri=http://localhost
  &state=[** STATE **]'

Ответ включает в себя access_token и refresh_token: 

{
  "access_token": "[** ACCESS_TOKEN  **]",
  "expires_in": 3599,
  "refresh_token": "[** REFRESH_TOKEN  **]",
  "scope": "openid https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile",
  "token_type": "Bearer",
  "id_token": "[** TOKEN ID **]"
}

Refre sh access_token с использованием refresh_token

Следующее тестирование refresh_token для обновления sh access_token: 

curl "https://www.googleapis.com/oauth2/v4/token" \
--request POST \
--verbose \
--connect-timeout 60 \
--silent \
--data 'grant_type=refresh_token
  &client_id=[** CLIENT_ID **]
  &client_secret=[** CLIENT_SECRET **]
  &refresh_token=[** REFRESH_TOKEN  **]'

Ответ включает access_token, но не refresh_token: 

{
  "access_token": "[** ACCESS_TOKEN  **]",
  "expires_in": 3599,
  "scope": "https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/drive openid",
  "token_type": "Bearer",
  "id_token": "[** TOKEN ID **]"
}

Сохранить refresh_token? ​​

Однако, похоже, что если я повторно использую изначально предоставленный refresh_token=[** REFRESH_TOKEN **], он все еще хорош в обновлении access_token до бесконечности.

Поэтому, похоже, refresh_token=[** REFRESH_TOKEN **] должно быть сохранено после первоначального согласия, что странно для службы OAuth 2.0.

Предыдущая публикация

Там была предыдущая переполнение стека публикация в марте 2015 года: Google OAuth 2.0 Refre sh Token

Чтобы получить новый refre sh токен для вашего клиенту сначала нужно отозвать существующий / старый токен refre sh, отменив доступ для своего клиента на вкладке Права доступа к учетной записи для вашей учетной записи Google, а затем снова запросить access_type = offline.

В другом Для служб OAuth 2.0 новый refresh_token предоставляется каждый раз, когда выполняется запрос refre sh, и не требует перехода на

Сводка

Есть ли Другой способ получить новый refresh_token каждый раз, когда он используется для получения нового access_token? Другие решения OAuth 2.0 не так сложны в обработке refre sh.

Спасибо, благодарю за любой ответ.

1 Ответ

0 голосов
/ 07 февраля 2020

Поскольку изначально предоставленный refresh_token действителен в течение неограниченного времени при обновлении access_token, и он работает, тогда ладно.

...