Стоит ли проверять имя и пароль пользователей при каждом запросе к api(guzzle)?

Делаю простое апи для своего сервиса(не SPA, простые запросы через к примеру через guzzle), где буду сам генерить пароли для доступа разным пользователям. По имени пользователя и этому паролю они будут авторизоваться. В случае SPA при логинизации возвращается токен, по которому api авторизирует пользователя и у токена есть время жизни, в случае истечении этого времени у пользователя уже нету доступа к апи. В моем случае выдавать токен вообще бессмысленно,верно? Так как запросы могут отправляться только несколько раз в день, а просто проверять имя и пароль пользователей при каждом запросе?
  • Вопрос задан
  • 253 просмотра
Решения вопроса 1
Fockker
@Fockker Куратор тега PHP
Потомок старинного рода Ипатьевых-Колотитьевых
Стоит ли проверять имя и пароль пользователей при каждом запросе к api(guzzle)?

Вот как всегда, в заголовке вопроса одно, а в тексте - ну совсем же другое.

В моем случае выдавать токен вообще бессмысленно,верно?

Верно

Но в общем случае, на который претендует вопрос судя по заголовку, проверять каждый раз не стоит, а стоит выдавать по логину и паролю ограниченный по времени токен при запросе на отдельную точку входа.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
DollyPapper
@DollyPapper
Токены хорошо использовать там, где сервис stateless, например в микросервисах, т.к. сессии по логину и паролю горизонтально хреново масштабируются. Вы мне кажется путаете токен и обычный пароль. Логин уже должен быть зашит в токен. В вашем случае если расширять ничего не планируете, используйте обычные сессии. В случае если хотите использовать токены вам их нужно 2
1)Access токен - токен по которому юзер собственно аутентифицируется в приложении. Этот токен имеет время жизни, обычно довольно маленькое, минут 15.
2)refresh токен - по этому токену раз в 15 минут фронт посылает запрос на определенный эндпоинт и апи выдает новый access токен.
Нахрена нужен refresh токен? Очень просто. Если наш access угнали, а приложение у нас stateless, то есть мы никакого состояния и информации о заходах пользователя на сервере не храним, то мы никак не можем заблокировать данный токен, вот тут вступает в силу refresh токен. Спустя 15 минут наш access станет не валидный и клиент пошлет запрос с refresh токеном, в ответ api пришлет новый access и тот токен который у злоумышленника станет не валидный.
В вашем случае да, подойдет обычная аутентификация на куках
Ответ написан
@dragonesis
SPA или не SPA не в этом суть.
Где собираетесь хранить пару логин-пароль? На клиенте? Безопасно? Думаю, что нет.
Далее, вам следует выбрать один из существующих механизмов авторизации и применить его на проекте. Это могут быть сессии, токены или что-то еще.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы