Как да направя маркера за влизане в 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

след като потребителят влезе успешно, изпратете ID токена на потребителя към вашия сървър чрез 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, потвърждавайки, че потребителят се е удостоверил, и след това изпраща нещо (обикновено бисквитка) обратно на клиента, казвайки „добре, удостоверих ви. Ето как поддържате удостоверявайки себе си до края на нашия разговор."

Това по-късно действие е доста стандартно и не е свързано със самия oauth. След това клиентът и сървърът комуникират както винаги - изобщо не се обменят oauth неща, вие разчитате на бисквитката (или еквивалент), за да поддържате удостоверяването клиент-сървър. Сървърът продължава да използва маркера за удостоверяване и маркера за опресняване, за да говори с Google.

https://developers.google.com/identity/sign-in/web/server-side-flow Мисля, че е най-доброто ръководство за това в момента. Или поне е най-добрият, който мога да намеря в момента. Има поне добра диаграма.

Ключовият момент е, че обменяте брилянтно наречения „код“ със сървъра (това, което наричах „еднократен код“). След като направите това, сървърът ви удостоверява с Google - и след това има токените за достъп/опресняване и вие комуникирате със сървъра, без да се налага да ги предавате.

person Prisoner    schedule 02.10.2015
comment
Благодаря, че отделихте време да ми изясните това. разчитайки на бисквитката - липсваше ми тази съществена част (в текущата версия разчитах на access_tokens) - person Mars Robertson; 02.10.2015
comment
Объркан съм: бисквитките се доставят, след като потребителят влезе или трябва да се извършат още няколко стъпки? - person elmazzun; 15.05.2018
comment
Сървърът ще достави бисквитка, след като получи кода от клиента и провери кода със сървърите на Google. Бисквитката е извън самия OAuth и е за удобство при комуникацията клиент-сървър. - person Prisoner; 15.05.2018
comment
Ами ако не искам да разчитам на бисквитки? Бих искал да използвам схема на токен на носител. Много пъти сървърът да е напълно без състояние (без да разчита на сесии) е желателно, особено когато се използва без сървър. Друг недостатък на използването на бисквитки е, че вашият сайт се поврежда изцяло, ако потребителят е активирал защитено сърфиране в своя браузър, което деактивира бисквитките. - 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 е невалиден (TTL е изтекъл). В този момент не знам какво да правя. Като проверя дали access_token преди е бил валиден, мога да го опресня... Трябва да има по-добър начин, затова зададох този въпрос на първо място :) - person Mars Robertson; 02.10.2015
comment
Да приемем, че сървърът получава заявка и access_token е невалиден (TTL е изтекъл). В този момент не знам какво да правя. Да използвате токена за опресняване, за да поискате нов токен за достъп? Иска ми се да можем да поговорим, мисля, че правиш това по-трудно, отколкото трябва. - 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