Сервис аутентификации пользователей.
Проект реализует базовый функционал аутентификации:
- Регистрация
- Авторизация
- Аутентификация
- Разавторизация
При регистрации пользователь записывается в БД и получает уникальную сигнатуру. Эта сигнатура в будущем используется как уникальный идентификатор токена доступа (access_token). Хранится сигнатура в виде заголовка JTI в токене, со стороны сервиса каждая сигнатура хранится в БД, связью один к одному.
При авторизации пользовательская сессия сохраняется в БД, чтобы в будущем он мог узнать свою историю в личном кабинете. А также получает пару токенов - access_token и refresh_token. Стоит отметить, что access_token автоматически устанавливается в http-only cookie, a refresh_token сохраняется в БД для будущей валидации и выдачи новой сессии. Дальнейшее распознавание пользователя будет вестись именно куке. При помощи refresh_token юзер может получить новую пару JWT-токенов.
Аутентификация пользователя происходит по куке, а также в отдельных случаях для защищенных частей сервиса придуман специальны роут - /verify. Он позволяет проверить - не были ли отозваны access_token-ы пользователя, если мы хотим удостовериться, что перед нами реальный пользователь, а не потенциальный злоумышленник.
В нашем сервисе есть два типа разавторизации - конкретной сессии и всех сессий. При выходе из конкретной сессии удаляется кука и рефреш токен из БД, чтобы не было возможности его переиспользовать. При удалении всех сессий - удаляется кука, удаляются все refresh_token-ы выпущенные для пользователя, а также меняется сигнатура в БД, которая является идентифиакатором выпущенных access-токенов. Таким образом, если пользователь нажал на выход из всех сессий - все выпщуенные access_token-ы для этого пользователя становятся невалидными.
Поднятие композиции сервиса:
make upТестирование сервиса:
pytestЛокальное развертывание:
- Установка зависимостей
make init- Запуск приложения
make runУчастники проекта: