Как сделать токен входа в Google действительным более 1 часа?

Я успешно реализовал вход в Google.

Я могу аутентифицировать пользователя и в ответ получаю токен. Однако срок действия токена истекает через 1 час.

expires_in: "3600"

Я пытался искать в документах - https://developers.google.com/identity/sign-in/web/reference, но не может найти параметр для продления срока службы токена.

введите описание изображения здесь


Что я на самом деле пытаюсь сделать?

https://developers.google.com/identity/sign-in/web/backend-auth

после того, как пользователь успешно войдет в систему, отправьте токен идентификатора пользователя на ваш сервер с помощью HTTPS.

Я отправляю токен с каждым запросом на сервер:

endpoint/get?access_token=" + access_token

А то на сервер звоню https://www.googleapis.com/oauth2/v3/tokeninfo

Итак, у меня есть токен, каждый запрос аутентифицируется, но после 1 часа работы метод tokeninfo возвращает false и мне нужно повторно аутентифицировать пользователя.

В своем коде я обошел это, сохранив все исторические access_tokens, и если клиент использует старый токен, я проверяю исторические данные и вручную выдаю новый токен, используя refresh_token (одно из моих разрешений — предоставить автономный доступ)


Так что да, мне было бы очень интересно узнать:

  • Как увеличить срок службы access_token?

OR

  • Учитывая ограниченный срок службы, как обеспечить аутентификацию запросов на серверной части?

person Mars Robertson    schedule 02.10.2015    source источник


Ответы (2)


Как отметил @DaImTo, вы не можете продлить срок службы access_token. Вы можете получить новый с помощью refresh_token, но часто, если вы пытаетесь сделать это на стороне клиента и имеете сервер, вам следует переосмыслить свой подход.

Похоже, что здесь вы выполняете две «аутентификации» — аутентификация клиента на сервере и аутентификация сервера на службе Google. Прямо сейчас сервер должен удерживать токен обновления, чтобы он всегда мог повторно аутентифицироваться в Google. Похоже, вы боретесь с тем, как аутентифицировать своего клиента на сервере после тайм-аута auth_token.

Как правило, клиент не должен отправлять на сервер ни access_token, ни refresh_token. Что он делает, так это то, что во время первого входа в систему клиент получает одноразовый код (от Google), который он передает на сервер. Сервер использует это, чтобы поговорить с Google и получить access_token и refresh_token, подтверждая, что пользователь аутентифицировал себя, а затем отправляет что-то (обычно файл cookie) обратно клиенту, говоря: «Хорошо, я аутентифицировал вас. Вот как вы сохраняете подтверждая свою подлинность для остальной части нашего разговора».

Это более позднее действие довольно стандартно и не связано с самим oauth. Затем клиент и сервер взаимодействуют, как всегда, - никакие материалы oauth не обмениваются вообще, вы полагаетесь на файл cookie (или его эквивалент) для поддержания аутентификации клиент-сервер. Сервер продолжает использовать токен аутентификации и токен обновления для связи с Google.

https://developers.google.com/identity/sign-in/web/server-side-flow Я думаю, что это лучшее руководство по этому вопросу на данный момент. Или, по крайней мере, это лучшее, что я могу найти на данный момент. По крайней мере, у него есть хорошая схема.

Ключевым моментом является то, что вы обмениваетесь с сервером блестяще названным «кодом» (то, что я называл «одноразовым кодом»). Как только вы это сделаете, сервер аутентифицирует вас с помощью Google, а затем у него есть токены доступа/обновления, и вы взаимодействуете с сервером без необходимости их передачи.

person Prisoner    schedule 02.10.2015
comment
Спасибо, что нашли время, чтобы прояснить это для меня. полагаться на файл cookie — мне не хватало этой важной части (в текущей версии я полагался на access_tokens) - person Mars Robertson; 02.10.2015
comment
Я запутался: файлы cookie доставляются после входа пользователя в систему или необходимо выполнить еще какие-то шаги? - person elmazzun; 15.05.2018
comment
Сервер доставит файл cookie после того, как получит код от клиента и проверит код на серверах Google. Файл cookie находится вне самого OAuth и предназначен для удобства взаимодействия клиент-сервер. - person Prisoner; 15.05.2018
comment
Что, если я не хочу полагаться на файлы cookie? Я хотел бы использовать схему токенов на предъявителя. Во многих случаях желательно, чтобы сервер был полностью апатридным (не зависел от сеансов), особенно при использовании без сервера. Еще одним недостатком использования файлов cookie является то, что ваш сайт полностью ломается, если в браузере пользователя включен безопасный просмотр, который отключает файлы cookie. - person agusterodin; 18.07.2021
comment
Предполагая, что Google делает это трудновыполнимым (короткий срок службы токенов), потому что они не хотят, чтобы вы использовали их в качестве сервера JWT, просто как простую платформу для одноразовой проверки личности. - person agusterodin; 18.07.2021

Токены доступа недолговечны и действуют всего один час, это не то, что вы можете продлить.

Что вам нужно сделать, так это взять токен обновления и получить новый токен доступа.

пример:

Вы берете refresh_token, который вы получили из исходного запроса, и отправляете его по HTTP: Примечание: grant_type=refresh_token

https://accounts.google.com/o/oauth2/token
client_id ={ClientId}.apps.googleusercontent.com&client_secret={ClientSecret}&refresh_token=1/ffYmfI0sjR54Ft9oupubLzrJhD1hZS5tWQcyAvNECCA&grant_type=refresh_token

ответ

{
"access_token" : "ya29.1.AADtN_XK16As2ZHlScqOxGtntIlevNcasMSPwGiE3pe5ANZfrmJTcsI3ZtAjv4sDrPDRnQ",
"token_type" : "Bearer",
"expires_in" : 3600
}
person DaImTo    schedule 02.10.2015
comment
Я сверяюсь с историческими данными и вручную выпускаю новый токен, используя refresh_token — похоже, я уже использую это — я не уверен, что это правильный способ, поскольку: 1) это требует меня для хранения устаревших токенов 2) любой, у кого есть исторический токен, автоматически обновляется до нового... Хорошо - по крайней мере, теперь я знаю, что токен недолговечен и не может быть продлен, поэтому я должен задать лучший вопрос - как сторона сервера узнает, когда в refresh_token? - person Mars Robertson; 02.10.2015
comment
Это требует, чтобы вы сохранили токен обновления, который не устарел, поскольку он будет работать до тех пор, пока пользователь не отзовет ваш доступ. Нет причин хранить токен доступа, просто получите новый, когда он вам понадобится. Вам просто нужно не забыть обновить токен доступа до истечения срока его действия. Серверная сторона, вероятно, не знает, когда ей нужно обновить его, и вы, разработчик, должны добавить в свой код, что пришло время его обновить. На каком языке вы здесь работаете? - person DaImTo; 02.10.2015
comment
Я храню refresh_token. Я использую node.js и Firebase, и вот мой код аутентификации кода: gist.github.com/stefek99/bafee8492128c63aa572 ••• Нет причин хранить access_token - Почему я храню access_token? Предположим, что сервер получает запрос и access_token недействителен (истек срок жизни). В этот момент я не знаю, что делать. Проверив, был ли access_token ранее действительным, я могу обновить его... Должен быть лучший способ, поэтому я задал этот вопрос в первую очередь :) - person Mars Robertson; 02.10.2015
comment
Предположим, что сервер получает запрос, а access_token недействителен (истек срок жизни). В этот момент я не знаю, что делать. Использовать токен обновления для запроса нового токена доступа? хотелось бы, чтобы мы могли поболтать, я думаю, вы делаете это сложнее, чем это должно быть. - person DaImTo; 02.10.2015
comment
Хотел бы мы поболтать :) Я все равно на работе, а мой ноутбук дома... Я проведу несколько экспериментов (позже)... Моя проблема в одном изображении: i.imgur.com/HRAOh9D.png ••• Я знаю, что могу использовать refresh_token для запроса access_token, но как насчет безопасности? Любой может возиться с запросом к серверу и потенциально получить токен, который ему не принадлежит... tokeninfo - когда истек срок действия, просто возвращает просроченный, и сервер не должен доверять никаким входным данным, поступающим от клиента, я не хочу возвращать новый access_token кому-либо :) - person Mars Robertson; 02.10.2015
comment
Вот почему вы не должны использовать токен обновления с клиентскими приложениями. Обычно он используется для серверной части. - person DaImTo; 02.10.2015
comment
Давайте продолжим это обсуждение в чате. - person DaImTo; 02.10.2015