Сохранить конечную точку OpenID, OP-локальный идентификатор и область? - PullRequest
1 голос
/ 05 сентября 2011

Я собираюсь создать таблицу базы данных для хранения логинов OpenID. Я думаю, что я включу эти три столбца в дополнение к заявленному идентификатору:

Вы храните эти поля?

Считаете ли вы целесообразным хранить эти поля ?, по следующим причинам:

  • Конечная точка OpenID: чтобы вы знали, какой поставщик OpenID аутентифицировал пользователя. Возможно, в будущем вы обнаружите, что один провайдер не очень заслуживает доверия, и тогда я думаю, что было бы полезно узнать, был ли аутентифицирован someuser.example.com этим провайдером.

  • OP-Local Identifier: я думаю, что это позволяет мне отслеживать пользователя, даже если она меняет свой User-Supplied Identifier. (Например, если ее пользовательский идентификатор - example.com/username, но она меняет его на whereelse.com/username, то я думаю, что локальный идентификатор OP останется неизменным (при условии, что пользователь продолжает использовать тот же поставщик OpenID) .

  • Область: я создаю многопользовательское веб-приложение, и если я сохраню область, будет легче узнать, могут ли два, казалось бы, разных идентификатора OpenID представлять одного и того же человека. ( Google использует направленные идентификаторы : ваш заявленный идентификатор зависит от области. Таким образом, у одного и того же пользователя может быть много разных заявленных идентификаторов.)

  • Версия: Если в будущем возникнет проблема безопасности с какой-либо версией OpenID, было бы полезно узнать, какие пользователи могут быть затронуты.

  • Область и конечная точка для сбора статистики.

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

1 Ответ

2 голосов
/ 05 сентября 2011
  • Конечная точка OpenID: заслуживает доверия? Насколько поставщик заслуживает доверия (или нет)? Он не утверждает ничего о данных, которыми он не владеет, поэтому он не может лгать. Будет ли он вести себя так, как вы ожидаете, - это совсем другое. Кроме того, поставщик может по какой-то причине иметь разные конечные точки для каждого пользователя (например, /server-username).
  • Локальный идентификатор OP: Вы не должны (потому что в спецификации так сказано), но да, в очень небольшом числе случаев это будет успешным. Однако гораздо чаще менять своего провайдера, чем менять свою личность. И если вы действительно хотите изменить свою личность, смена провайдера (или регистрация другой учетной записи) не так уж и сложна. Один случай, когда это могло бы помочь, - это когда пользователь потеряет доменное имя, на котором размещена заявленная идентификационная информация. Однако для поставщика гораздо более вероятно, что он прекратит предлагать свои услуги, и вам также необходимо подготовиться к этому (например, предлагая хранить несколько идентификаторов для одного пользователя, например SO). И если вы готовы к этому, единственный случай, когда это поможет, охватывается другим механизмом.
  • Царство: я не понимаю, как это тебе поможет. От Google вы получаете два совершенно разных идентификатора, без возможности их корреляции, если только вам не требуется адрес электронной почты (и зачем вам тогда область?).
  • Версия: маловероятно, и версия может измениться с новым запросом (потому что поставщик может обновить). Тем не менее, если вы действительно хотите знать, кто из ваших пользователей может пострадать, и каким-то образом ожидать, что они что-то получат, прочитав об этом на вашем веб-сайте, тогда да, это может быть полезно.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...