Как вы спроектируете аутентификацию в API
Вопрос
Как вы спроектируете аутентификацию и авторизацию для API веб- и мобильного клиента?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Пароли: Argon2 или bcrypt, ограничение попыток, общие сообщения об ошибке
Короткий access JWT и refresh с ротацией, хранение refresh на сервере
Отзыв: удаление refresh, версия токенов, выход со всех устройств
Транспорт: HTTPS, httpOnly cookie для веба или защищённое хранилище в мобильном
Авторизация: роли плюс проверка объектов на сервере в каждом запросе
Аудит входов, 2FA для критичных действий
Что могут спросить следом
- Где хранить токены во фронтенде?
- Как сделать вход через Яндекс ID?
Разбор
Образцовый ответ: «Пароли храню через Argon2 или bcrypt, на вход ставлю ограничение попыток по аккаунту и IP и отвечаю общим сообщением, чтобы не раскрывать, какие email есть. После входа выдаю короткий access JWT, минут на 15, и долгий refresh. Refresh храню на сервере в виде записи с хешем, при обмене выдаю новый и инвалидирую старый; повторное использование старого считаю кражей и гашу всю сессию. Так работает и выход со всех устройств: удаляю все refresh пользователя, а access сам истечёт через минуты, для критичных случаев добавляю версию токенов. Для веба refresh лежит в httpOnly Secure cookie, access в памяти приложения; для мобильного в защищённом хранилище платформы. Авторизация на сервере в каждом запросе: роль даёт право на тип действия, а доступ к конкретному объекту проверяю фильтром по владельцу или организации. Плюс журнал входов, уведомление о новом устройстве и вторая проверка для опасных действий».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.
Предыдущий вопрос
Код-ревью эндпоинта входа и проверки токена
Следующий вопрос
Как не допустить ошибок контроля доступа