Как или когда следовать за перенаправленными OpenID?

В настоящее время я внедряю аутентификацию OpenID для веб-сайта. Во время тестирования я заметил, что Google принимает разные версии заявленных идентификаторов профиля Google, например:

Интересно, что проверенный идентификатор также отличается (для образцов выше, в том же порядке):

Конечно, это делает поиск соответствующей учетной записи пользователя довольно трудным, если не сказать невозможным. Интересно, что все вышеуказанные идентификаторы работают для Stackru. Поэтому я подумал, что должен быть какой-то шаг нормализации, который я пропускаю в своей реализации - или ТАК делает какое-то специализированное вуду, чтобы все исправить.

Глядя на 7.2 Норматизация спецификации аутентификации OpenID, я нашел это:

Затем идентификаторы URL ДОЛЖНЫ быть дополнительно нормализованы путем следующих перенаправлений при извлечении их содержимого и, наконец, применения правил в Разделе 6 [RFC3986] к конечному целевому URL. Этот окончательный URL-адрес ДОЛЖЕН быть отмечен проверяющей стороной в качестве заявленного идентификатора и использоваться при запросе аутентификации.

Переадресация заявленных идентификаторов не очень помогает, так как у меня все еще есть два разных идентификатора:

Глядя на перенаправления проверенных идентификаторов, гораздо полезнее, хотя я всегда получаю следующее:

Хорошо, похоже, я должен следить за перенаправлениями подтвержденных идентификаторов, а не заявленных идентификаторов.

Теперь возникает вопрос: безопасно ли следовать перенаправлениям заявленных / проверенных идентификаторов, например, перед поиском в БД следующим образом:

do {
  user = lookup(verifiedId)
  if (user is null)
    response = fetchUrl(verifiedId)
    if (response.location is null) {
      break # no redirect, jump out of loop, unknown user
    } else {
      verifiedId = response.location # use redirect location
    }
} while (user is null)

return user;

Если да, я подозреваю, что это следует делать не только при поиске пользователя, но и при сохранении нового идентификатора, верно?

(Если я действительно буду следовать перенаправлению, у меня есть еще один вопрос о потенциальных злонамеренных перенаправлениях, но мне придется подождать, пока я не получу ответ на этот вопрос. В любом случае, возможно, он устарел)

Источник

2 ответа

Open ID 2.0 говорит, что во время открытия

Идентификаторы URL ДОЛЖНЫ быть далее нормализованы путем следующих перенаправлений при извлечении их содержимого и, наконец, применения правил в Разделе 6 [RFC3986] к окончательному целевому URL. Этот окончательный URL-адрес ДОЛЖЕН быть отмечен проверяющей стороной в качестве заявленного идентификатора и использоваться при запросе аутентификации.

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

Результат считается "заявленным идентификатором" (CI). Затем вы будете танцевать ассоциацию и определите, верно ли это утверждение.

Примечание. У некоторых поставщиков есть "хорошо известный" URL-адрес поставщика OpenId (OP), например Google. Если вы заметили процесс входа в Stackru, вы можете просто нажать кнопку Google вместо заполнения формы. В этом варианте "общеизвестный" OP URL не является CI пользователя. Пользователь не предоставил вам CI. Вам нужно будет подождать, пока вы закончите танец аутентификации, и Google скажет вам, кто пользователь.

Именно в этот момент (после получения успешного обратного вызова ассоциации от поставщика OpenId) у вас будет идентификатор для пользователя. В соответствии с разделом 9.1 вы ДОЛЖНЫ получить либо openid.claimed_id а также openid.identityили ни одно из полей, если вы делаете что-то необычное с расширениями (я не очень знаком с этим аспектом спецификации).

Теперь вы должны хранить openid.claimed_id с вашей стороны - это будет идентификатор, уникальный для этого пользователя. Это может отличаться от того, что пользователь изначально предоставил вам. Он также может отличаться от того, где вы оказались (после перенаправления на предоставленный пользователем идентификатор). У поставщика OpenID есть последнее слово.

В отношении безопасности следуют перенаправления на предоставленный пользователем идентификатор. Здесь не должно быть проблемы. Перенаправления позволяют пользователю делегировать проверку подлинности поставщику по своему выбору. Независимо от того, куда вас ведут перенаправления, вы в конечном итоге попросите, чтобы поставщик OpenId установил с вами связь. Когда вы делаете этот запрос, вы предоставляете (нормализованный) заявленный идентификатор, и поставщик может решить, желают ли они нести ответственность за заявленный идентификатор, и они (каким-то образом, исходя из своей бесконечной мудрости) разрешат пользователю владеть этим заявленным идентификатор.

Возвращаясь к Google, заявленный идентификатор Google в итоге предоставит вам не похожий на ваши примеры выше. Пример, который они используют openid.claimed_id=https://www.google.com/accounts/o8/id/id=AItOawl27F2M92ry4jTdjiVx06tuFNA ( источник).

Надеюсь, это поможет...

Источник

Я использую электронную почту в качестве уникального идентификатора в этом случае. Вы можете запросить его в Google, см. http://code.google.com/intl/en/apis/accounts/docs/OpenID.html.

Источник
Другие вопросы по тегам