Предлагает ли Google UserInfo API какие-либо гарантии?

Несколько месяцев назад мы внедрили Google OAuth для нашего веб-сайта. На данный момент два пользователя (из ~ 100) имеют неполные профили информации о пользователе. Мы звоним по адресу 'https://www.googleapis.com/oauth2/v1/userinfo? 'с действительным токеном, а ответ json содержит только [locale, Verified_email, email, id].

Документы (https://developers.google.com/accounts/docs/OAuth2Login#userinfocall) не являются явными, но то, как я их интерпретирую,

Ответ должен ВСЕГДА включать: [идентификатор, адрес электронной почты, подтвержденный_почта, имя, данное_имя, имя_семейства, часовой пояс, пол] и ИНОГДА включать: [изображение, язык]

Кто-нибудь знает, какая гарантия идет с UserInfo API? Должен ли я отклонять неполные профили как недействительные? Есть ли другое объяснение того, почему профиль был неполным?

ОБНОВЛЕНИЕ 3/6/14
Мне удалось воспроизвести проблему. Мы отправляем пользователя на запрос Google, две области:

https://www.googleapis.com/auth/userinfo.profile
и
https://www.googleapis.com/auth/userinfo.email

Насколько я могу судить, Google не позволяет пользователям выбирать, какие области они разрешают. Все или ничего. Однако мне удалось удалить область userinfo.profile из URL-адреса и перезагрузить страницу. Это привело к тому, что меня отправили обратно с действующим токеном, но не с правильной областью действия. Мне нужно попасть в конечную точку tokeninfo и убедиться, что разрешена правильная область.


person Charles    schedule 25.02.2013    source источник


Ответы (4)


Вы тоже используете OpenID? Я сильно подозреваю, что у этих пользователей на самом деле нет действительных токенов OAuth для UserInfo, но вы получаете данные, соответствующие более слабому разрешению OAuth. В идеале спросите этих пользователей, какие данные для вашего веб-сайта отображаются на странице безопасности их учетных записей Google, и сравните их с данными функционального пользователя, например. сам.

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

person djechlin    schedule 04.03.2013
comment
Я не уверен, что понимаю ваш ответ. Чтобы уточнить, мы НЕ используем OpenID. Мы используем рабочий процесс на стороне сервера. Пользователь возвращается на страницу OAuth Google, возвращается с кодом, который обменивается (на стороне сервера) на токен через accounts.google.com/o/oauth2/token конечная точка - person Charles; 07.03.2013

NB: вот что я думаю:

Я также некоторое время работал с OAuth и неоднократно сталкивался с этой проблемой, например, с профилями Facebook. Честно говоря, я не понимаю, почему запрос должен возвращать неполные данные (при условии правильной области действия), кроме того, что фактический профиль от поставщика неполный (хотя для вас не имеет смысла иметь эти [locale, verified_email, email, id] и нет [firstName, lastName]). Например, в некоторых профилях нет изображения профиля и т. Д.

В общем, я бы сказал: это не гарантируется (и это касается не только Google). Раньше я писал сервер идентификации OAuth, и OAuth ничего не делает (если я его не пропустил) для обеспечения того типа данных, который вы должны предоставлять через API. Вы должны проверить данные перед их сохранением.

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

person Sthe    schedule 07.03.2013

У меня была такая же проблема. Для некоторых профилей область «userinfo» не возвращает given_name и family_name. Пока я не выясню, почему это так, я использую пустые строки для этих двух, если значения не возвращаются. Я не могу предположить, что Google позволяет людям создавать учетные записи Google, не предоставляя некоторых значений для имени и фамилии. Google API глючит, медлителен и сбивает с толку. Поэтому я бы предпочел предположить, что это проблема API.

person Allen King    schedule 31.12.2014

Попробуйте v3 API userinfo, он довольно надежно возвращает given_name:

https://www.googleapis.com/oauth2/v3/userinfo

person Kevin Burke    schedule 06.09.2018