Прежде всего позвольте мне начать с того, что этот вопрос связан не с различными реализациями openID и oAuth. В этом есть много классов.
Мой вопрос заключается в том, что делать после аутентификации пользователя:
Любые идеи?
На ваш вопрос должны быть основные части:
Обычно эти два не обрабатываются по-разному, если поставщик удостоверений (IP) является вашим собственным, который был наиболее распространенной в веб-приложениях до сих пор.
При использовании поставщика OpenId, такого как Google, часть аутентификации отделена от вашего элемента управления. Вы получите ответный знак, говорящий вам, если пользователь аутентифицирован или нет. Токен обычно будет содержать следующие утверждения: имя, адрес электронной почты и именованный идентификатор, где последний является уникальным идентификатором идентификатора на IP-адресе.
Пока все хорошо.
Трюк теперь, когда вы спрашиваете, как мне авторизовать этого пользователя?
Ну, есть несколько подходов к этому.
Во-первых, когда вы создаете локального пользователя в своей системе, вы можете предварительно заполнить значения Name и Email на основе требований, которые вы получаете от IP. В этом процессе вы можете начать и сказать, что все пользователи, у которых есть профиль, хранящийся в вашей системе, авторизованы или вы можете разработать дополнительные процессы, которые добавят все детали, которые вам нужно знать о пользователе.
Затем, как вы избегаете, чтобы пользователь не перерегистрировался, если они переключаются с google на facebook как IP?
Здесь все становится сложнее. Наиболее распространенным утверждением, которое Google, Yahoo, Facebook предоставит вам, является адрес электронной почты и имя. Итак, что вы можете сделать, старайтесь соответствовать заявляемому требованию с существующими клиентами в вашем приложении. Однако это не является отказоустойчивым, поскольку люди могут иметь разные электронные письма в разных системах.
Значение имени также небезопасно.
В нашей настройке мы начинаем с сопоставления писем, так как мы знаем, что большинство IP-адресов проверяют адреса электронной почты. Это уменьшит количество дубликатов. После этой проверки мы начинаем собственный процесс проверки, где цель состоит в том, чтобы узнать, зарегистрирован ли человек. Этот процесс ищет номер мобильного телефона клиентов в нашей базе данных, и если совпадение найдено, мы отправляем пользователю единовременный пароль для подтверждения правильного владения номером телефона.
Поскольку логин - это временная настройка, мы создали простую таблицу SQL, которая отображает внешние идентификаторы для наших номеров клиентов. Это позволяет нам реализовать такую логику проверки вне всех наших веб-приложений (и тем самым уменьшить избыточность кода).
Самый простой способ показался бы мне, чтобы иметь базовую пользовательскую таблицу, в которую вы добавляете пользователя в регистр и имеете дополнительную таблицу 1: n, где вы сохраняете возможные аутентификации. Возможно, вам нужно больше одной таблицы, если есть методы, которым требуется больше столбцов, чем другие.
Я реализовал вход через OpenID из Google и встретился с аналогичными проблемами. Я использовал openid library из janrain.
Я не создал отдельную таблицу для openid. Вместо этого я использовал вторичные электронные письма (вторичные электронные письма хранятся в таблице пользователей).
При входе в Google можно запросить электронные письма пользователей (я считаю, что там есть одна и та же возможность в любом другом провайдере openid). После того, как я получаю ответ от google, что пользователь подключен, я смотрю в таблицу пользователей. Если предоставленная электронная почта была найдена в таблице (неважно, является ли она первичной или вторичной), я вхожу в систему пользователя. Если письмо не найдено, я спрашиваю пользователя, есть ли у него учетная запись. Если да, ему предлагается войти в систему с существующим логином/паролем, после чего я добавлю дополнительный адрес электронной почты пользователю. Если у пользователя нет учетной записи, создается новая учетная запись.
Поэтому для этих трюков вам не нужны специальные новые таблицы.