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

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

11 голосов
/ 10 июня 2011

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

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

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

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

Идентификаторы 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 ]

1 голос
/ 20 июня 2011

Открытый идентификатор 2.0 говорит, что во время обнаружения

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

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

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

Примечание. Некоторые провайдеры имеют «общеизвестный» URL-адрес провайдера OpenId (OP), например, Google. Если вы заметили процесс входа в StackOverflow, вы можете просто нажать кнопку 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 ( source ).

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

0 голосов
/ 20 июня 2011

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

...