Вопрос: решения для регистрации и аутентификации пользователя

Question

[Ilusha]

Добрый день.
Это мой первый пост, и в нем, собственно, я хочу попросить:

• какие готовые решения для аутентификации и регистрации пользователя вы посоветуете использовать на ресурсе, который не содержит критичных конфиденциальных данных?
• какие готовые решения посоветуете использовать для сторонней аутентификации через популярные ресурсы рунета?
• Существуют ли комплексные решения, объединяющие предыдущие два пункта?

В данный момент я первый разрабатывают небольшую веб-систему сам и с нуля(javasript, php), набираюсь опыта, поэтому очень рад буду рад дельным советам.

Answer 1

[zednight]

Все решения для авторизации есть в php (механизм сессий). Но дабы еще упростить задачу можно использовать фреймворки типа: Yii, Kohana, Zend. Точно знаю, что для Yii в руководстве по созданию блога полностью разжевывается как сделать авторизацию. Есть только одно но, скорее всего у Вас не получится использовать авторизацию фреймворка и работать вне самого фреймворка, следовательно придется его учить. Для авторизации через ресурсы интернета для фреймворков есть модули, называются обычно OAuth. Как правило полно мануалов, как их интергрировать в фреймворк. Но опять же все это в рамках фреймворков.

Comments

[Ilusha]

Фреймворки это хорошее решение, я на самом деле бы с радостью их использовал (работал с CodeIgniter), но в рамках текущей задачи их использование не представляется возможным.
Я думал попробовать реализовать решение, описанное: здесь или здесь и прикрутить уже какой-нибудь виджет для авторизации через соц.сети/почтовики. Но моих знаний в области криптографии не хватает.

Собственно цель — создание удобной и относительно безопасной системы регистрации и аутентификации пользователей.
Реализовать простую систему с хешем можно быстро, но вопрос в другом:
сервис, который специализируется на хранении пользовательских данных, не сделает ли это лучше меня?

[zednight]

Я думал попробовать реализовать решение, описанное: здесь или здесь и прикрутить уже какой-нибудь виджет для авторизации через соц.сети/почтовики

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

[Ilusha]

Спасибо за ссылку. Я думал о сессиях, но не вникал в особенности их работы с точки зрения безопасности. Искал решение в области криптографии. Но сейчас, взглянув на них(сессии) более подробно, понял что Вы правы.

А как Вы относитесь к возможности аутентификации через коллектор учетных записей, например loginza?

[zednight]

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

[Ilusha]

Писать под api каждого сервиса — это, пардон, тот еще геморой.

Я поэтому и спросил про loginza (альтернатив не искал еще): смысл этого коллектора в том, что он не только агрегирует в своем виджете аутентификацию через популярные ресурсы(получается, я буду использовать только одно API, а не кучу разных), но и позволят регистрироваться пользователям, для них это выглядит как регистрация на конечном ресурсе в виджете.
Пользователи получают openId, с которым можно аутентифицироваться на других ресурсах, а база с аутентификационными данными хранится у сервиса.
По крайней мере, я так понял смысл работы сервиса.

Но, пожалуй, реализация своей системы аутентификации лишней не будет.

Answer 2

[Assorium]

У большинства крупный почтовых сервисов есть свое API. Гляньте uLogin. Очень простой способ аутентификации. Можно также запросить дополнительные поля.

Comments

[Ilusha]

Это естественно. uLogin мне понравился, лаконично.
Но, как понял, сервис — это конструктор, для виджета, и для каждого сервиса нужно дописывать интеграцию со своей системой.
В этом варианте выше упомянутая http://loginza.ru/ отличается удобством внедрения:
Она является прослойкой между API крупных почтовиков/соц.сетей и конечным ресурсов, на котором уже производится интеграция только с одним API.

Есть конечно риски, поскольку мы складываем все яйца в одну корзину: ляжет loginza, и аутентификация из соц.сетей будет недоступна… Но то, что этот проект купил яндекс дает какие-то гарантии.

[Assorium]

uLogin и Loginza это одно и тоже, только uLogin попроще в интеграции, а также разработке с локального сервера.
У него также есть готовые модули для огромного количества CMS.

Я не рекламлю его. Я просто работал и с тем и с тем вариантом. uLogin понравился больше. Покупка Яндексом ничего сервису не дала. После покупки они внесли обновление, после которого, у меня все перестало работать и я все перенес на uLogin, где мог.

[Ilusha]

Да я никого и не упрекаю в рекламе.
Я предположил, что uLogin лишь конструктор, поскольку на сайте проекта не нашел API.
Был бы рад посмотреть.

[Assorium]

ulogin.ru/constructor.html — конструктор
ulogin.ru/faq.html — faq

Он проще, чем Вы думаете :)

[Ilusha]

Скорее всего так и есть, начитался сегодня про методы аутентификации с использованием криптографии =)
Я просто смутно понимаю как работает эта(uLogin) аутентификация.

[Assorium]

Если просто. Скрипт кидает клиента на выбранную oAuth систему, после сайт uLogin получает ответ от oAuth системы и создает POST запрос с токеном в виде параметра на тот url, что Вы указали, а все данные по этому токену хранит у себя на сервере в течении пары минут.
Вы создаете GET запрос с сервера с токеном и получаете данные о пользователе.

[Ilusha]

Понял, спасибо большое =)

Answer 3

[gis]

В части теории, на будущее, имейте ввиду, что на сегодня имеются следующие «протоколы» внешней аутентификации:
— OpenID — категорически не рекомендуется, как самый не безопасный и устаревший
— OAuth v.1 — так же не рекомендуется к использованию в новых продуктах по причине низкой безопасности
— OAuth v.2 — специалистами по ИБ пока ещё допускается его применение, хотя есть информация о методе взлома
— SAML v.2 — наиболее на сегодня безопасный и следовательно рекомендуемый к использованию, но его внедрение имеет очень много «подводных камней»

Comments

[Ilusha]

Спасибо, обязательно учту.