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

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

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

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

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 membership, я просто смотрю на таблицу аутентификации и ищу учетные данные и получаю соответствующего пользователя. Если пользователи не существуют, я создаю нового пользователя и добавляю запись в таблицу аутентификации.

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

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

9
architecture asp.net-mvc-3 authentication dotnetopenauth openid

2 ответов

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

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

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

5

мы просто храним url-адрес утверждения openid. Может потребоваться запросить у поставщика дополнительную информацию, например имя пользователя. Самое главное-разделить членство и аутентификацию.

наши схемы

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

Users
-----
Username
Password

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

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

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

1