Is openid.claimed_id static?

Я читаю о Федеративный вход для пользователей аккаунта Google, чтобы выяснить, как я могу войти в систему в веб-приложение, используя их аккаунт Google.

Итак, к концу процесса Google возвращает идентификатор, предоставленный Google, который добавляется как openid.claimed_id. Это означает, что веб-приложение использует этот идентификатор для распознавания пользователя и разрешения доступа к функциям и данным приложения. Мой вопрос в том, является ли этот идентификатор статическим? Могу ли я использовать этот идентификатор для повторения идентификатора того же пользователя?

Ответ 1

Да. Учитывайте значение openid.claimed_id как имя пользователя. Особенно в Google, но это верно для любого провайдера OpenID, который действительно реализует "направленную идентификацию", не считайте это имя пользователя совместимым с другими веб-сайтами. Любая другая полагающаяся сторона, помимо вашего собственного веб-сайта, получит по-другому значение искомого идентификатора для одного и того же пользователя Google.

Кроме того, не забудьте обработать этот assert_id как с учетом регистра.

Ответ 2

Конкретный ответ на ваш вопрос можно найти в Документация API OpenID API Googles:

Идентификатор, предоставленный Google, который не имеет никакого отношения к фактическому имени или паролю учетной записи пользователя, является постоянным значением; он остается постоянным, даже если пользователь изменяет свое имя пользователя и/или адрес электронной почты Google. Этот идентификатор также является "направленной идентичностью", то есть Google возвращает другое значение каждой полагающейся стороне. Google использует параметр запроса openid.realm для распознавания полагающейся стороны, поэтому, если стороннее приложение решает изменить это значение, все пользовательские идентификаторы будут изменены.

Ответ 3

На самом деле, я просто столкнулся с экземпляром, где google assert_id изменился для моего тестового пользователя. Я пришел к концу внедрения OpenID в мое приложение, и, по всей видимости, имя пользователя request_id в данных ответа не изменилось.

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

Я не уверен, как справиться с этим на данный момент, но я думаю, что это вызовет меня за цикл. После первоначальной аутентификации пользователи регистрируются на сайте (как и следовало ожидать) и настраивают имя экрана. Как мы можем проверить, является ли тот же пользователь, если искомый_изменился? Мы, конечно, не можем использовать адрес электронной почты в соответствии с наилучшими практиками.

ИЗМЕНИТЬ

Теперь у меня есть пирог на моем лице! Я пропустил одну маленькую деталь, которая оказалась важной деталью. Я меняю среду разработки и размещаю на другом v-хосте. Это эффективно изменяет сферу, и это изменит ответ assert_id в соответствии с документами.

Это был хороший урок для меня, так как я собирался реализовать OID в субдомене, в котором в моем коде автоматически устанавливалась область. Теперь я сэкономил себе головную боль по дороге, потому что я бы не смог использовать одну и ту же базу данных пользователей во всех других поддоменах без нарушения идентификации.

область обновления

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ

Как замечательная сторона - даже если вы разрабатываете свое решение OpenID для одного из ваших поддоменов, может быть разумным указать область в домене верхнего уровня.

например, openid.realm = http://*.yourdomain.com

Это позволит вам расширить свою страницу входа во все ваши поддомены и сохранить идентификатор пользователя через них.

(необязательно) Аутентифицированная область. Определяет домен, который заканчивается пользователю предлагается доверять. (Пример: "http://*.myexamplesite.com" ) Это значение должно соответствовать домену, определенному в openid.return_to. Если этот параметр не определен, Google будет использовать URL-адрес, указанный в openid.return_to.