наилучшая практика для хранения oauth и локальных методов аутентификации? - PullRequest
Новая
       16

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

19 голосов
/ 23 июня 2011

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

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

Кроме того, что, если они захотят войти в систему с помощью Твиттер-кредитов, затем Tumblr, а затем любой другой службы? Я мог бы оставить поле для каждого типа, но это может быть немного громоздким. Не лучше ли мне сохранить другую таблицу «методов аутентификации» из-за отсутствия лучшего термина, чтобы у меня были отношения «один ко многим» между пользователями и способы их аутентификации?

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

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

Ответы [ 2 ]

8 голосов
/ 23 июня 2011

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

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

User table:
id int
username varchar
email varchar
password varchar

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

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

Тогда ваш скрипт авторизации делает что-то вроде этого:

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

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

2 голосов
/ 23 июня 2011

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

...