Промяна на разрешения с Google OAuth

Надстройвам акаунти, за да използвам новия обхват plus.login, така че тествах добавянето на потребител само с обхват userinfo и след това влизане отново с добавен plus.login. Резултатът беше, че беше въведен нов запис в панела за оторизиран достъп и маркерът за достъп, върнат от последното повикване, имаше само userinfo разрешение. Тествах това, като направих потвърдено повикване с токен, както и се опитах да изброя хора.

Това очаквано поведение ли е и ако е така, трябва ли да отменя стария токен предварително? Виждам, че е възможно с действие /revoke. Премахване от страна на сървъра на Oauth токен

Актуализация: Съответна същност. Това използва скъпоценния камък Omniauth на Ruby. Всъщност не съм сигурен как потребител някога може да види повече от 1 запис в панела за оторизиран достъп, но при това обстоятелство можех да видя 2. И след тестване на различни сценарии вчера, имах около 6 записа всички принадлежат към едно и също приложение! Обърнете внимание, че никога не съм променял клиентския идентификатор и всъщност имам само един клиентски идентификатор.

Надявам се, че ситуацията, която описах, може да бъде възпроизведена от други; това е просто въпрос на хакване на URL адреса от страна на Google, за да се премахне обхватът plus.login, и след това да влезете отново, като запазите URL адреса такъв, какъвто е.

Актуализация (2): Също така открих този проблем: „Не трябва да изисквате потребителска информация. профил или plus.me в комбинация с този обхват, тъй като те са имплицитно включени и биха създали объркващ диалогов прозорец за разрешения за вашия потребител." Всъщност това е нещо повече от проблем с UX разрешения; изглежда Google всъщност няма да съхранява обхвата "plus.me" срещу потребителя, така че това означава, че винаги ще показва диалоговия прозорец за разрешения за OAuth, дори ако потребителите вече са дали разрешения (мисля, защото прави проста проверка за равенство и отбелязва плюс .me се изисква, но не се съхранява срещу потребителя).

Актуализация (3): Грешката за използването на грешно влизане беше причинена от моя код, който прави нещо като user.login || user.signup без актуализиране на данните за токена при влизане. Така че сега актуализира токена за достъп и токена за опресняване след всяко влизане. (Все още не разбирам защо трябва да има повече от един токен за комбинация клиент-потребител.)


oauth-2.0 google-oauth
person mahemoff    schedule 15.03.2013    source източник

Отговори (2)


arrow_upward
3
arrow_downward

Може би не отменяте токена за вашия предварително удостоверен клиент, преди да издадете нов?

Можете да тествате дали отмяната след надграждане на обхват работи със следните демонстрации на JavaScript:

  1. Упълномощавайте чрез тази страница. (Не прекъсвайте връзката с оторизирания клиент)
  2. Надстройте вашето разрешение като използвате тази страница, която включва обхвата на календара като пример и която има същия клиент.
  3. Сега, ако погледнете в страницата ви с издадени субтокени за оторизации, ще забележите, че има два записи, съответстващи на всеки клиент.
  4. Отменете от втората страница, като опресните и щракнете върху бутона за прекъсване на връзката.
  5. Върнете се към страницата ви с издадени субтокени за оторизация. И двата набора издадени оторизирани субтокени вече ги няма.

Тествах това допълнително и направих промени в проекта, като добавих обхвата на устройството. След добавяне на обхвата към клиентския проект на API и оторизиране на допълнителен клиент, отмяната на някой от токените ще отмени всички оторизирани клиенти от този проект.

Ако надграждате съществуващи упълномощени идентификационни данни от друг клиент, по-старият токен трябва да бъде отменен в момента, в който надграждате съществуващия си токен, за да избегнете екземпляри на идентификационни данни, които не работят според очакванията.

Въпреки това, както можете да видите от демонстрацията, отмяната на токени от същия API клиент ще отмени допълнително издадени токени за удостоверяване, така че не е нужно да се притеснявате за отмяната на вече издадени токени.

Най-добрата причина за отмяна на по-стари токени (напр. вашия токен за опресняване с обхват userinfo.email) е, че по-късно може да се опитвате да направите извикване на API за нов обхват, използвайки този токен, въпреки че този токен не е надстроен, за да включва допълнителните обхвати и може да въведе странни грешки.

Последна бележка: да се надяваме, че потребителите ще свикнат по-често да преглеждат своите издадени токени за оторизация от страницата за управление на приложения в Google+ което върши по-добра работа за дедупликиране на екземпляри на свързани приложения.

person class    schedule 15.03.2013
comment
Благодаря, тази демонстрация основно възпроизвежда повечето от това, за което бях объркан, т.е. има втори запис, тъй като мислех, че надстройката просто ще го презапише, но виждам, че това е очаквано поведение. (Въпреки че все още не съм сигурен защо се връща грешният токен; ще го тествам отново.) Все още имам същия практически въпрос относно това коя е най-добрата практика за надграждане на съществуващи токени, тъй като в идеалния случай бих искал само един токен (дори ако мога точно да извършвам обаждания с правилния токен всеки път, не е необходимо). Така че предполагам, че сървърът ми трябва да отмени всички други токени, когато надстроеният токен се върне? - person mahemoff; 15.03.2013
comment
Допълнителни бележки, добавени към отговора, защото ми свърши мястото в коментара. - person class; 15.03.2013
comment
Благодаря, това е много полезно, за да потвърдите, че другите трябва да бъдат отменени. Така че звучи така, сякаш предполагате, че когато потребител щракне върху бутона за влизане, моят сървър трябва първо да се опита да отмени всеки съществуващ токен и да поиска новия едва когато получи успешен отговор от сървъра на Google. С други думи, между заявката на потребителя и отговора на сървъра на приложението за пренасочване към Google се осъществява двупосочно движение от сървър към сървър. - person mahemoff; 15.03.2013
comment
другите трябва да бъдат отменени. Това е само за стари клиенти и трябва да се направи, за да се избегне наличието на токени за опресняване, които не се държат както очаквате. Въпреки това отмяната на токен от същия клиент (напр. добавяте услуга към конзолата на API, за да актуализирате заявените от вас обхвати и вашият clientid/тайна остават същите) след получаване на допълнителен токен ще отмени новия ви токен, както е показано в демонстрацията. - person class; 15.03.2013
comment
Благодаря за тези подробности, зададох и допълнителен въпрос относно страницата за управление на приложения. stackoverflow.com/questions/15444692 / - person mahemoff; 16.03.2013

arrow_upward
2
arrow_downward

Това не звучи като правилно поведение. Можете ли да получите токена за достъп от по-късното обаждане и да го включите в https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=TOKEN_GOES_HERE - това ще покаже обхватите, за които е упълномощено.

На коя платформа внедрявахте също? Ако имате фрагмент, който може да помогне!

Актуализация: Опитах да добавя plus.login след удостоверяване преди това и получих нов диалог за съгласие, така че всичко изглеждаше доста гладко там. Може би проблемът е специфичен за клиента?

person Ian Barber    schedule 15.03.2013
comment
Проверих токена; това имах предвид с проверка и се върна с оригиналния обхват, който беше поискан (без plus.login). Добавена е Gist връзка с кода, както е поискано. - person mahemoff; 15.03.2013
comment
С актуализацията какво се случи след това? Видяхте ли 2 записа в панела за достъп (t.co/BIv3RN67MK) и какъв обхват се връща, когато всички /tokeninfo. - person mahemoff; 15.03.2013