2013-07-10 3 views
2

Я разработал службу на основе REST, используя Express и изначально начал внедрять аутентификацию самостоятельно. Простая аутентификация имени пользователя/пароля, гдеREST/Веб-аутентификация как услуга?

  • пароли шифруются с использованием BCrypt
  • данные пользователя + хэшируются пароли хранятся в MongoDB
  • проверки проверки пароля сделано.
  • маркеры аутентификации (ограниченное TTL) генерируется/подтверждена

У меня есть некоторые знания о Node.js, но далеко не достаточно, чтобы заставить меня чувствовать себя комфортно, выкатывает свою собственную проверку подлинности (Логин/регистрация) механизм.

По этой причине я хотел бы заменить свой внутренний механизм чем-то другим.

Что-то проверенное, расширяемое, подключаемое и прост в использовании.

Учитывая количество защищенных веб-сайтов/API-интерфейсов REST, основанных на Node.JS, я уверен, что есть готовые решения, которые могут предложить люди/компании, которые могут быстро и эффективно внедрять разработчиков быстро, не беспокоясь о аспекте безопасности/пользователя.

Я ищу even higher level of abstraction, а не библиотеки таких, как passport или everyauth. То, что обеспечивает функциональность вне коробки, способной выполнять мои требования, включая:

  • обеспечение Войти Главная/Регистрация Главная/Профиль страницы
  • различные модули аутентификации (Google, facebook, GitHub, .. ..)
  • сохранение информации о пользователе (+ учетные данные, если требуется) в хранилище данных (mongoDB).
  • запомнить
  • забыл пароль/сброс пароля

Так что вопрос здесь:

  • Существует out-of-the-box решения, как, что доступно, которые предлагают более высокий уровень абстракции, чем паспорт/каждыйauth/...?
  • Если хотите, вы порекомендовали бы некоторые из этих готовых решений?
  • Должен ли я забыть о понятии outsourcing my user authentication и просто начать смотреть на паспорт и все это и начать реализацию моих требований с использованием этих библиотек?
  • Можно ли сосредоточиться на моей бизнес-логике и не беспокоиться ни о каком аспекте, касающемся аутентификации пользователей (писать страницы входа/регистрации, внедрять забытые пароли/сбросить пароли, хранить информацию о пользователе в БД).
+0

Вам удалось подойти к ответу тем временем? – Rocco

ответ

1

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

Что касается обслуживания? Нетрудно настроить безопасность. Таким образом, для небольшого проекта запуска, возможно, более экономичным для интеграции с другой услугой. Можете взглянуть на Mozilla Persona. Это built on Node и довольно прямолинейно.

Если вы пытаетесь опрокинуть свой собственный опыт, вы получите некую внешнюю экспертизу, а НЕ ДЕЛАЙТЕ делать такие глупые вещи, как использовать алгоритм хеширования, такой как SHA1 для хранения паролей. Вместо этого используйте что-то вроде bcrypt. Тогда есть и другие вещи: не храните журналы сервера на созданном им сервере. Выровняйте все журналы в другом месте, поэтому, если есть вторжение, у вас есть криминалистика, чтобы вернуться к тому, что произошло.

+0

API должен быть защищен. Я не могу «получить сцепление» с не защищенным API. Если данные пользователя украдены/манипулированы из-за проблем с безопасностью, у меня будут другие проблемы, кроме тяги. Я знаю об основах (хеширование + соление, использование SSL, ....). Каков ваш опыт работы с Mozilla Persona? – ddewaele

+0

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

Смежные вопросы