Наилучшая практика для хранения методов аутентификации oauth AND?

Если мне нужно запустить службу, которая позволила бы пользователям проходить аутентификацию через "локальные" комбинации имени пользователя и пароля и ТАКЖЕ любое количество служб OAuth - как могла бы выглядеть эта пользовательская модель данных?

Обычно, если я сам обрабатывал все логины, в "пользовательской" базе данных (при условии, что MySQL), поля имени пользователя и пароля будут необходимы как ненулевые. Но если мои пользователи просто захотят войти в систему Facebook, я бы просто сохранил автотекст Facebook и не имел локального имени пользователя или пароля.

Кроме того, что, если они хотят войти в систему с помощью Twitter-Creds, а затем tumblr, а затем независимо от службы? Я мог бы сохранить поле для каждого типа, но это может стать немного громоздким. Будет ли я лучше хранить другую таблицу "методов проверки подлинности" из-за отсутствия лучшего термина, поэтому у меня могут быть отношения "один ко многим" между пользователями и их аутентификация?

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

Если какое-либо из сделанных мной допущений неверно, прошу прощения, пожалуйста, поправьте меня.

Ответ 1

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

Идентификация в вашем приложении должна быть абстрактной из источника аутентификации. То, что я закончил настройкой, выглядит примерно так:

User table:
id int
username varchar
email varchar
password varchar

Authentication profile table:
user_id int
service enum('website','google','facebook')
token varchar

[Для дальнейшей нормализации сделайте сервис собственной таблицы с мета-полями службы. ]

Тогда ваш auth script делает что-то вроде этого:

Ищите имя пользователя/адрес электронной почты
Определить известные профили аутентификации
Посмотрите, проверяет ли вход для любых известных профилей проверки подлинности и auth, или возвращает недопустимые учетные данные

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

Ответ 2

Я думаю, что вам нужна локальная система проверки подлинности (возможно, по причинам устаревшего?), а также поддержка для входа в систему пользователей с использованием делегированной аутентификации. Стандартом для делегированного auth является OpenID. Возможно, вам стоит взглянуть на библиотеки и образцы OpenID, которые должны дать вам представление о хранении учетных данных OpenID. К сожалению, Facebook и Twitter не поддерживают OpenID, но поток почти такой же, т.е. Ваша модель данных не изменится. Мы внедрили пользователя OpenID для поддержки входа и регистрации на основе OpenID. Чтобы поддерживать локальную аутентификацию, мы использовали провайдер OpenID. Другими словами, мы оба являемся потребителем и поставщиком. Таким образом, даже локальная система auth основана на стандартах. Теперь ответ на ваш вопрос о схеме. У нас есть источник (локальный, твиттер, facebook, google, yahoo, AOL) и адрес электронной почты в виде составного ключа вместе с токеном и/или паролем в таблице аутентификации. Мы разрешаем пользователям изменять отображаемые имена и иметь уникальный URL-адрес тщеславия, который также является частью этой схемы. У пользователей есть возможность установить пароль при входе через OpenID, так как для мобильных устройств им нужен пароль (не так много поддержки OpenID на мобильном устройстве). OAuth решает немного другой вариант использования, когда вы имеете дело с авторизацией больше, чем с аутентификацией. Помогает ли это? Если у вас есть какие-либо вопросы, не стесняйтесь комментировать, и я был бы рад предоставить более подробную информацию - я просто не хочу путать вас со слишком большой информацией на данный момент.