Обьясние принцип аунтификации на сайте?

Question

[magary4]

что сейчас в тренде для простой аунтификации пользователей на сайте? если рассматривать что-то проще чем OAuth2 ?

как я понял передача логина и пасса и получение в ответ куки - подход уже устрарел

что счас рационально использовать?

передавать каждым запросом заголовок bearer md5(username+pass) ?

Comments

[magary4]

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

можете это момент чуть подробнее обьяснить? у меня на клиенте только юзерней и пасс, откуда на стороне клиента секретные слова? метка времени? пока запрос дойдет до сервера она же изменится

[magary4]

>> md5 это не шифрование от защиты пароля!
а чем простым зашифровать на javascript?

[Steely]

Кого ты собрался шифровать? Пароль что ли перед отправкой? Установи https и не занимайся ерундой

Answer 1

[Алексей Волегов]

Да нет ни каких движух в этом направлении, все по старому, по логическому верному пути — все зависит от поставленных задач!

Куки для обычных сайтов.

OAuth для авторизации через соц сети, и то, после перенаправления на ваш портал и обработки что чел авторизуется через сторонний сервис вы ему те же печеньки присваиваете. Писать для своего портала OAuth провайдер — а оно вам надо? В топ плане будете ли вы предоставлять api для работы с данными пользователя?

OpenID вроде уже ни кто не юзает, но он для авторизации через сторонний/ваш сайт без предоставления дополнительного API

По поводу bearer — это для RESTful API сайтов. Когда пишется один backend для веба и мобильных приложений. Тогда веб как и мобила подписывает любые запросы "bearer {token}". Ну и да, не стоит путать "{token}" и md5(user+pass). Сначала вы делаете авторизацию пользователя по login+pass, затем выдаете ему уникальный token (по сути тот же session_id, но не храните статус пользователя). А как вы его уже генерируете на сервере, дело 3-е. Но да, не стоит md5(login + pass) делать =)

Comments

[magary4]

>> А как вы его уже генерируете на сервере

кроме генерации токена нужно еще его наверное делать истекаемым

[Алексей Волегов]

Ну да. Вы можете это воспринимать как сессию с единственным ограничением, rest api не хранит состояние. Нельзя сделать анкету из 2 шагов, и сохранять промежуточные значения на сервере. Frontend должен сразу присылать ответы на все вопросы. Но это правило для rest =)

Можете token положить вместе с user или в отдельную табличку. Я например в redis по ключу храню, быстро ищется и получается информация по пользователю.

[magary4]

ну если записывать прямо в юзера, то только один одновременный логин возможен, вот появилась мысль чтоб не усложнять таблицей токенов, писать в юзера в поле массив из 5 токенов ["5f05abcd7b38a53458844ac28a4aa52f","5f05abcd7b38a53458844ac28a4aa522","5f05abcd7b38a53458844ac28a4bb52f"] и при каждом новом логине удалять первый элемент, и вставлять в конец. типа стек LIFO

[Алексей Волегов]

magary4: не але, token выдается на длительный срок и вы так будете "разлогинивать" человека. Можете хоть на memcache сделать, по ключу (token = ключ)

Answer 2

[Steely]

А что не так с куками?

Answer 3

[Hakhagmon]

Использую куки на большом проекте, полет нормальный.
ну и про сессии не стоит забывать

Answer 4

[Emil Revencu]

sha256(user+pass+RANDOM)
где RANDOM получаем заранее с сервера
А на сервере сравниваем полученный sha256(user+pass+RANDOM) с sha256(user+pass+RANDOM) из базы данных
и убиваем RANDOM
Каждый раз запрос будет меняться