Блог

Прежде всего позвольте мне начать с того, что этот вопрос касается не разных реализаций OpenID и OAuth. Существует множество классов, посвященных этим.

Мой вопрос в том, что делать после аутентификации пользователя:

• Как добавить этого пользователя в таблицу user в базе данных?
• Как обрабатывать разные логины для одного и того же пользователя? (Пример Реми Шарпа предлагает кое-что для OpenID)
• Как объединить OAuth и OpenID в базе данных?

Есть идеи?

Ваш вопрос касается основных частей:

1. Аутентификация
2. Авторизация

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

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

Пока все хорошо.

Теперь, как вы спрашиваете, фокус в том, как мне авторизовать этого пользователя?

что ж, есть несколько подходов к этому.

Во-первых, когда вы создаете локального пользователя в своей системе, вы можете предварительно ввести значения имени и электронной почты на основе утверждений, которые вы получаете от IP. В этом процессе вы можете начать и сказать, что все пользователи, у которых есть профиль, хранящийся в вашей системе, авторизованы, или вы можете разработать дальнейшие процессы, которые добавят все детали, которые вам нужно знать о пользователе.

Тогда, как вы избежите того, что пользователь не будет повторно зарегистрирован, если он переключится с Google на facebook в качестве IP?

Здесь все становится сложнее. Наиболее распространенное требование, которое Google, Yahoo, Facebook предоставят вам, — это адрес электронной почты и имя. Итак, что вы можете сделать, это попытаться сопоставить входящее требование с существующими клиентами в вашем приложении. Однако это небезопасно, поскольку у людей могут быть разные электронные письма в разных системах.

Значение name также небезопасно.

В нашей настройке мы начинаем с сопоставления электронных писем, поскольку знаем, что большинство IP-адресов проверяют адреса электронной почты. Это значительно сократит количество дубликатов. После этой проверки мы запускаем наш собственный процесс проверки, цель которого — увидеть, зарегистрирован ли пользователь уже. Этот процесс ищет номер мобильного телефона клиента в нашей базе данных, и если найдено совпадение, мы отправляем клиенту одноразовый пароль для подтверждения правильного владения номером телефона.

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

Мне кажется, что самый простой способ — создать базовую таблицу пользователей, куда вы добавляете пользователя при регистрации, и иметь дополнительную таблицу 1: n, где вы сохраняете возможные аутентификации. Возможно, вам нужно больше одной таблицы, если существуют методы, которым требуется намного больше столбцов, чем другим.

Я внедрил вход через OpenID из Google и столкнулся с аналогичными проблемами. Я использовал библиотеку OpenID от janrain.

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

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

Таким образом, вам не нужны специальные новые таблицы для этих трюков.