Интеграция OpenID и oauth в качестве системы входа на веб-сайт, входа в систему и аутентификации
Прежде всего позвольте мне начать с того, что этот вопрос не касается различных реализаций OpenID и OAuth. Об этом есть много занятий.
Мой вопрос в том, что делать после аутентификации пользователя:
- Как добавить этого пользователя в таблицу пользователей в базе данных?
- Как обрабатывать разные логины для одного и того же пользователя? (Пример Реми Шарпа предлагает что-то для OpenID)
- Как объединить OAuth и OpenID в база данных?
Есть идеи?
3 answers
Ваш вопрос состоит из основных частей:
- Аутентификация
- Авторизация
Обычно эти два параметра не рассматриваются по-разному, если поставщик удостоверений (IP) является вашим собственным, что до сих пор было наиболее распространенной настройкой в веб-приложениях.
При использовании поставщика OpenID, такого как Google, часть аутентификации отделена от вашего контроля. Вы получите обратно токен, сообщающий вам, аутентифицирован пользователь или нет. Маркер обычно будет содержать следующие утверждения: Имя, адрес электронной почты и Именованное удостоверение, где последнее - уникальный идентификатор удостоверения по IP.
Пока все идет хорошо.
Теперь фокус в том, как вы спрашиваете, как мне авторизовать этого пользователя?
Ну, есть несколько подходов к этому.
Во-первых, когда вы создаете локального пользователя в своей системе, вы можете предварительно заполнить Имя и значения электронной почты на основе утверждений, которые вы получаете с IP-адреса. В этом процессе вы можете начать и сказать, что все пользователи, у которых есть профиль, сохраненный в вашей системе, авторизован, или вы можете разработать дальнейшие процессы, которые добавят любые сведения, которые вам необходимо знать о пользователе.
Тогда как избежать того, чтобы пользователь не был перерегистрирован, если он переключится с google на facebook в качестве IP-адреса?
Вот тут-то все и становится сложнее. Наиболее распространенное утверждение, которое вам предоставят Google, Yahoo, Facebook, - это адрес электронной почты и имя. Итак, что вы можете сделать, это попытаться сопоставить поступающую заявку с существующими клиентами в ваше приложение. Однако это небезопасно, так как у людей могут быть разные электронные письма в разных системах.
Значение имени также небезопасно.
В нашей настройке мы начинаем с сопоставления электронных писем, так как знаем, что большинство IP-адресов проверяют адреса электронной почты. Это значительно сократит количество дубликатов. После этой проверки мы начинаем наш собственный процесс проверки, цель которого - проверить, зарегистрирован ли человек уже. Этот процесс ищет номер мобильного телефона клиента в нашей базе данных, и если совпадение найдено, мы отправляем одноразовый пароль для клиента, чтобы подтвердить правильность владения номером телефона.
Поскольку вход в систему зависит от времени, мы создали простую таблицу SQL, которая сопоставляет внешние идентификаторы с номерами наших клиентов. Это позволяет нам реализовать такую логику проверки вне всех наших веб-приложений (и тем самым уменьшить избыточность кода)
Мне кажется, что самый простой способ - создать базовую таблицу пользователей, в которую вы добавляете пользователя при регистрации, и иметь дополнительную таблицу 1:n, в которой вы сохраняете возможные проверки подлинности. Возможно, вам нужно больше одной таблицы, если есть методы, которым требуется намного больше столбцов, чем другим.
Я реализовал вход в систему через OpenID из Google и столкнулся с аналогичными проблемами. Я использовал библиотеку openid от janrain.
Я не создавал отдельную таблицу для openid. Вместо этого я использовал вторичные электронные письма (вторичные электронные письма хранятся в таблице пользователей).
При входе в систему через Google можно запрашивать электронные письма пользователей (я полагаю, что такая же возможность есть у любого другого поставщика openid). После того, как я получу ответ от Google о том, что пользователь вошел в систему, я заглядываю в таблицу пользователей. Если предоставленный адрес электронной почты был найден в таблице (не имеет значения, является ли он основным или вторичным) Я регистрирую пользователя. Если электронное письмо не найдено, я спрашиваю пользователя, есть ли у него учетная запись. Если да, то ему предлагается войти в систему с существующим логином/паролем, после чего я добавляю дополнительный адрес электронной почты пользователю. Если у пользователя нет учетной записи, создается новая учетная запись.
Таким образом, вам не нужны специальные новые таблицы для этих трюков.