OpenID: уникальный URL-адрес идентификатора? каковы различия между идентификаторами

В спецификациях OpenID говорится:

  • Идентификатор:

Идентификатор - это всего лишь URL-адрес. Весь поток протокола аутентификации OpenID доказывает, что конечный пользователь является владельцем URL-адреса.

  • Заявленный идентификатор:

Идентификатор, который конечный пользователь говорит, что он принадлежит, хотя это еще не подтверждено потребителем.

  • Проверенный идентификатор:

Идентификатор, который конечный пользователь доказал для своего потребителя.

  • Поставщик удостоверений:

Также называется "IdP" или "Server". Это сервер проверки подлинности OpenID, который пользовательский контакт использует для криптографического доказательства того, что конечный пользователь владеет искомым идентификатором. То, как конечный пользователь выполняет аутентификацию своего поставщика удостоверений, выходит за рамки OpenID Authenticaiton.

  • Является ли уникальный URL-адрес идентификатора? Что это такое?

  • Если это не уникально, есть ли что-то уникальное, чтобы потребитель мог различаться между разными пользователями на одном и том же URL-адресе конечной точки OpenID?

  • В чем разница между IdP и URL-адресом идентификатора?

В других местах я прочитал термин "URL конечной точки OpenID".

  • Является ли URL конечной точки OpenID таким же, как IdP? Итак, IdP также является URL-адресом?

В качестве примера возьмем Googles OpenID. Когда какой-либо сайт запрашивает у меня идентификатор OpenID, я использую URL OpenID https://www.google.com/accounts/o8/id. Это URL-адрес идентификатора? Если это так, то это явно не является уникальным. Часто, когда я вернусь в настройках своей учетной записи на этом сайте о моем имени входа OpenID, он не показывает этот введенный URL, но он расширил его как-то как https://www.google.com/accounts/o8/id?id=AltOawk.... Этот URL-адрес теперь кажется уникальным.

  • Какова цель https://www.google.com/accounts/o8/id? Это URL-адрес конечной точки OpenID? Или это URL-адрес IdP (если это что-то другое)?

  • И какова цель https://www.google.com/accounts/o8/id?id=AltOawk...? Это действительно уникально и всегда одинаково для моей учетной записи Google? Так что URL-адрес идентифицирует меня?

  • Почему они не использовали https://www.google.com/accounts/o8/id?u={google-username} вместо этого загадочного ...?id=AltOawk...?

  • Каков URL-адрес идентификатора в случае Google?

  • Что такое URL-адрес конечной точки OpenID? (Что такое URL-адрес IdP?)

Я прошу, потому что я пытаюсь реализовать свою конечную точку OpenID.

  • Является ли URL конечной точки OpenID таким же, как URL-адрес идентификатора?

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

  • Если конечный пользователь использует этот "общий" URL-адрес, как я могу перенаправить/переслать его в моей реализации конечной точки OpenID на "конкретный" /уникальный (идентификатор?) URL-адрес? Или как я могу сделать это, чтобы различать разных конечных пользователей по одному и тому же URL OpenID?

В моей текущей реализации, когда я включаю трассировку отладки, первым запросом я получаю режим checkid_setup. В спецификациях говорится, что я получаю Идентификационный номер здесь. Из-за того, что я ввел на потребительский сайт (и моя трассировка отладки говорит то же самое), то есть "общий" URL (URL конечной точки OpenID). То есть не уникальный URL.

  • Нужно ли мне сейчас делать переадресацию? Спецификации ничего не говорят об этом. Где я могу указать "конкретный" URL? (В моем случае это URL http://{endpoint-url}?u={endpoint-username}.)

Существуют также термины "OpenID-сервер" (URL) и "OpenID delegate" (URL).

  • Как эти термины относятся к другим терминам выше? Все равно что URL конечной точки OpenID?

  • Что такое идентификатор OpenID? То же, что и URL-адрес идентификатора OpenID?

См. также связанный с этим вопрос: Как OpenID отличается между разными входами на одной конечной точке OpenID?

(Мета-вопрос: Должен ли я, возможно, разделить это на множество независимых вопросов SO? Боюсь, что я не могу получить ответы на все мои вопросы в противном случае.)

ОТВЕТЫ

Ответ 1

Хорошо, поскольку я только что исправил мою реализацию конечной точки SMF OpenID (читайте подробности о некоторых очень связанных проблемах, у меня было здесь), где я сделал несколько предположений относительно этих отношений. Конечно, это не доказывает их правильность (поэтому, пожалуйста, поправьте меня). Вот они:

  • URL-адрес идентификатора = конечная точка OpenID = IdP

  • Конечная точка OpenID не уникальна. Это одинаково для всех конечных пользователей этой конечной точки.

  • Проверенный идентификатор URL = идентификатор

  • URL-адрес проверенного идентификатора уникален. Он связан с учетной записью пользователя конечной точки.

  • https://www.google.com/accounts/o8/id - это URL конечной точки OpenID Google.

  • https://www.google.com/accounts/o8/id?id=AltOawk... - это идентификатор проверенного идентификатора Google OpenID.

  • Хэш, содержащий URL-адрес идентификатора Google OpenID, также связан с областью OpenID (пространство имен потребительских доменов, где этот идентификатор OpenID остается действительным). Это одна из причин не просто быть именем пользователя.

  • О том, как предоставить уникальный URL-адрес проверенного идентификатора, см. здесь.

Мне все еще неясно:

  • Какие еще существуют причины, которые Google использует для хэшированного id; он мог бы также использовать id?u={username}&oidrealm={...}.

  • В чем причина наличия такой области OpenID?

  • В чем разница между URL-адресом идентификатора и заявленным URL-адресом идентификатора?

Ответ 2

Вот мое понимание. Я просто отвечаю на два последних вопроса в собственном ответе. Надеюсь, кто-то найдет это полезным.

В чем причина наличия такой области OpenID?

Область используется для обеспечения безопасности. В принципе, return_url проверяется на соответствие области, а спецификации OpenID говорят, что они ДОЛЖНЫ совпадать. Google сделал этот шаг дальше и предоставляет уникальные проверенные идентификаторы для каждой области. Они могли бы сделать так, как вы предложили, и вернуть царство в свой идентификатор, но тогда вы могли бы сказать, посмотрев два проверенных идентификатора, были ли они одним и тем же конечным пользователем или нет. Я думаю, что они пытаются сохранить свои идентификаторы без идентификации информации. (ироничный, нет?)

В чем же разница между URL-адресом идентификатора и заявленным URL-адресом идентификатора?

Заявленный идентификатор - тот, который указал конечный пользователь. Это не их уникальный идентификатор. Yahoo - хороший пример этого. Они позволяют указать yahoo.com как ваш идентификатор, войти в свою учетную запись yahoo и вернуть уникальный идентификатор для пользователя openid. Это просто упрощает процесс для конечного пользователя. (И увеличивает вероятность того, что они будут использовать yahoo.com как их openid!)

Ответ 3

И какова цель https://www.google.com/accounts/o8/id?id=AltOawk...? Это действительно уникально и всегда одинаково для моей учетной записи Google? Так что URL-адрес идентифицирует меня?

Если я все правильно понял, ответ "Да, это!"

Почему они не использовали https://www.google.com/accounts/o8/id?u= {google-username} вместо этого загадочного...? id = AltOawk...

Я предполагаю, что они хотят быть в безопасности для будущих изменений в вашей учетной записи, если вы, например (сейчас или в будущем), сможете изменить свое имя пользователя, то вам, вероятно, понравится, что это будет отражено в вашем заявленном OpenId -Индикатор - но тогда у вас будут проблемы! все ваши регистрационные данные для вашего старого заявленного идентификатора не будут оценены. Подробнее здесь: http://wiki.openid.net/w/page/12995200/OpenID-Security-Best-Practices и здесь: http://blog.nerdbank.net/2008/07/case-for-case-sensitive-openid-url.html