Скажите пожалуйста правильно ли я представляю схему идентификации пользователя. И есть ли другие популярные схемы, которые принципиально отличаются от описанной ниже.
1. На странице авторизации пользователь через форму вводит логин и пароль.
2. Далее происходит запрос на сервер например по адресу /auth. К этому запросу в виде post-данных или в виде заголовков запроса добавляются логин/пароль
3. Сервер проверяет полученные логин/пароль. Кодирует их например при помощи md5 и сверяет с тем, что есть в БД
4. Если они совпадают, то происходит генерация токена
5. И далее этот токен отправляется на клиент. И на клиенте токен сохраняется например в куку, или в локалсторадж, или в сервис, который активен на протяжении всего времени работы приложения
6. Теперь при любом запросе не по адресу /auth, а по другому, этот токен будет прикреплён в виде заголовка или post-данных к запросу. А сервер будет сверять полученный токен и токен на своей стороне для конкретно этого пользователя.
7. Если они совпали, то запрашиваемая информация отправляется на клиент.
8. Если не совпали, то сервер бьёт тревогу. Он понимает, что сессию перехватил злоумышленник
9. При нормальной работе через определённое политикой сервера время в целях безопасности токен устаревает. И генерируется новый
10. Соответственно требуется повторная регистрация. Чтобы пользователя не кошмарить повторным заполнением формы, клиент сам достаёт из какого-нибудь своего хранилища логин/пароль, который ранее был введён пользователем. И отправляет его на сервер, незаметно для пользователя
11. Далее происходит возврат к пункту 3 и всё повторяется.
Средний
Средний
Средний
Средний
Простой
