Как правильно реализовать авторизацию и аутентификацию на сайте?

Question

[korsamc]

Как я понимаю данные пользователя необходимо хранить в БД, запрашивать и сверять их,далее от простого к сложному я пришёл к тому,что для сохранения пользователя на сайте необходимы куки и сессии, их тоже писать в бд? и через какое то время удалять?Вообще могли бы подсказать, как правильно составить алгоритм,как я понимаю большинство используется уже готовые библиотеки, но хотелось бы большей практике,реализовать все это самому.

Answer 1

[Владислав]

Да, самый простой вариант, это:
Пользователь отправляет нам на сервер логин+пароль.
Сервер сверяет с данными в БД, если всё хорошо, то генерирует большую случайную строку(Токен), которую добавляет как запись в БД (UserID, Token), после этого отправляет клиенту токен, чтоб тот установил у себя его в куки (заголовок Set-Cookie).
Теперь браузер клиента на каждый запрос будет отсылать на сервер куку и мы можем, обращаясь к БД на поиск строки из куки, получать данные о пользователе.
Но так как хранение в БД не всегда эффективно, токены хранят иногда в быстрых БД, таких как Redis или MemCached.

По поводу сессии:
Иногда, чтоб не ходить в главную БД на каждый запрос, некоторые данные выносят из главной БД(В тот же Redis, MemCached или даже просто в файл на диске с именем токена). Просто теперь, хранится не только токен, но и по имени токена сразу же получают некоторые данные, например, что у пользователя ID=42 и что он администратор.

Через какое то время удалять?

День, неделя, несколько часов, зависит от задачи.
Например, некоторые сайты хранят сессию сутки, но если нажать галочку "Запомнить меня", то срок может увеличится до недели или месяца.
Сервисы оперирующие с деньгами или чем-то, что может представлять ценность, делают сессии от 10 минут.

Comments

[korsamc]

Благодарю за целостный ответ, а то начитавшись тонну информации в голове образовалась каша)

[Chupaka]

А если использовать JWT (https://ru.wikipedia.org/wiki/JSON_Web_Token ) — то сессии и в базе хранить не надо :)

[Владислав]

Chupaka, да, в этом случае сессия хранится на клиенте, но у JWT есть и минусы, например:
Мы не можем отозвать токен, до того как он сам протухнет.
Не можем хранить в нём не безопасную информацию, которая может понадобится серверу, так как клиент её может спокойно прочесть.

[Chupaka]

Владислав Фурсов, про отзыв, например, тут: https://stackoverflow.com/questions/31919067/how-c...
А небезопасную информацию (какую, например?) можно и зашифровать, разве нет?

[Владислав]

Chupaka, я знаю про отзыв(костыль), но нужно будет проверять БД(Что токен не в чёрном списке) перед тем как принять JWT токен, так чем он будет лучше простого токена в БД(проверка на существование токена)? Так же, лазить проверять JWT токен в БД, противоречит тому, для чего собственно и создавался JWT(Уменьшение запросов в БД и построение stateless сервисов, которые слепо доверяют JWT)
Про небезопасную: мало ли что вздумается хранить, что клиенту не нужно показывать или он был бы не рад этой информации. Как надуманный пример: одному из пользователей мы завысили цены на сайте в 2 раза, для этого вынесли эту настройку в JWT, он её достал и не обрадовался.
Конечно, мы можем зашифровать, никто не мешает, но это усложняет приложение.

Хороший способ использовать JWT, это распределённые системы, где пользователь обращается к публичному апи по своему токену, а внутри, приложения используя свои приватные апи, используют JWT.

Не стоит использовать технологию ради технологии, если она не даёт преимуществ или если она только всё усложняет.

[Chupaka]

Ну, много тысяч-миллионов активных токенов в базе и несколько сотен отозванных, которые по серверам рассылаются один раз и не должны строго синхронно с них удаляться, прожив несчастные пару десятков минут — это всё же разные вещи, согласитесь.

А шифрование вообще ничего не усложняет. Одну строку зашифровать-расшифровать ничего не стоит, тем более тут никто не гонится за многовековой криптостойкостью.