Хранение необходимой информации OpenID

Question

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

• войти в систему, используя только openId (пользователь может быть просто проверен, посетив openid провайдера. Нет необходимости создавать пользовательскую учетную запись с email-паролем),
• По электронной почте / паролю (пользователь зарегистрировался на сайте, заполнив форму)
• Прикрепите открытые идентификаторы к своим учетным записям (openids + электронная почта для одной учетной записи).

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

Table: Users
UserId => PK
... => Custom info. Not related to authentication.

Table: Authentication  
AuthenticationId => PK
LoginId => (when custom site membership => email address) (when openId => openid unique address)

UserId  => FK to Users.
Provider =>(when custom site membership => "CUSTOM") (when openId => openid provider address)  
Password => filled when using custom membership. empty when using open id.

Теперь, когда пользователь входит в систему, используя ли openid / custom членство, я просто просматриваю таблицу аутентификации, ищу учетные данные и получаю соответствующего пользователя.Если пользователей не существует, я создаю нового пользователя и добавляю запись в таблицу аутентификации.

• Основной вопрос: достаточно ли хранения Provider и LoginId (см. Приведенные выше комментарии, чтобы узнать, что хранится в этих полях) для хранения аутентификации openid?Должен ли я хранить какие-либо дополнительные данные, чтобы, когда пользователь вернется, я мог аутентифицировать его / ее на основе моих сохраненных данных?

• Предлагаете ли вы другой (более эффективный) подход для реализации этого?
  Спасибо.

Answer 1

Сохраните ClaimedIdentifier для пользователя openid - не адрес провайдера.Заявленный идентификатор - это то, что проверяет протокол OpenID, является уникальным для пользователя, а также потенциально обеспечивает переносимость между провайдерами OpenID.

Кроме того, поскольку заявленные идентификаторы OpenID 2.0 могут быть объявлены устаревшими в OpenID Connect (незавершенный преемник OpenID2.0), также может быть в ваших интересах записать URI конечной точки провайдера OpenID и адрес электронной почты, указанный провайдером в записи пользователя.Пока не используйте их как часть процесса аутентификации, но, записав их, вы сможете позже определить, каким адресам электронной почты вы доверяете (т.е. предположим, что вы решаете адреса электронной почты, утвержденные Googleзаслуживают доверия) и позволяют пользователю таким образом перенести свою учетную запись в учетную запись OpenID Connect с использованием этого подтвержденного адреса электронной почты.Это также снизит опасность того, что область вашего веб-сайта (обычно http://yourdomainname.com) изменяется и приводит к изменению всех заявленных идентификаторов пользователей Google, которые могут быть трагически восстановлены только с их адреса электронной почты.

Я также рекомендую использовать разные таблицы для разных типов аутентификации. Здесь есть несколько преимуществ. Наиболее важным является то, что с архитектурной точки зрения становится труднее создать дыру в безопасности на вашем веб-сайте, которая может позволить кому-товведите (например) OpenID в поле имени пользователя и пустой пароль, чтобы он отображался как совпадение базы данных и вход в систему без какой-либо реальной аутентификации. Во-вторых, он обеспечивает более гибкую модель на случай, если вы хотите добавить третью аутентификацию.механизм, а не для того, чтобы ваша таблица «Аутентификация» росла горизонтально для всех пользователей. Например, OAuth 2.0 и «OpenID Connect» каждый, вероятно, будет вводить новые типы аутентификации на вашем сайте, когда вы добавляетеподдержка на протяжении многих лет, и добавление новых таблиц для обработки новых типов данных, кажется, подходит лучше.

Answer 2

Мы просто храним URL претензии openid.Вы можете запросить дополнительную информацию у провайдера, например, имя пользователя.Наиболее важным является разделение членства и аутентификации.

Наша схема была

Profiles
--------
UserId
FirstName
LastName
etc.

Users
-----
Username
Password

Profiles.UserId - это просто строковое свойство, в котором хранится либо внутреннее имя пользователя, либо их URL-адрес заявки openId,в зависимости от того, как они зарегистрировались.

После успешной аутентификации (с использованием внутреннего имени пользователя / пароля или внешнего провайдера) мы просто устанавливаем их куки аутентификации, используя либо их внутреннее имя пользователя, либо их URL-адрес претензии.Чтобы получить профиль пользователя, достаточно просто найти профилировщик, в котором (UserId == User.Identity.Name).

Преимущество заключается в том, что пользователь может изменить способ аутентификации в любой точке (возможно,переключение на внутреннюю учетную запись или использование другого провайдера).