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

Question

[Kolya Vantukh]

Делаю простое апи для своего сервиса(не SPA, простые запросы через к примеру через guzzle), где буду сам генерить пароли для доступа разным пользователям. По имени пользователя и этому паролю они будут авторизоваться. В случае SPA при логинизации возвращается токен, по которому api авторизирует пользователя и у токена есть время жизни, в случае истечении этого времени у пользователя уже нету доступа к апи. В моем случае выдавать токен вообще бессмысленно,верно? Так как запросы могут отправляться только несколько раз в день, а просто проверять имя и пароль пользователей при каждом запросе?

Comments

[Ипатьев]

"По имени пользователя и этому токену" - это по логину и паролю :)

[Kolya Vantukh]

Роман Юрьевич Ипатьев, сути же не меняет

[Ипатьев]

ну раз не меняет, то зачем здесь токен? ;-)

[Ипатьев]

просто вопрос задан как-то путанно.
"Так как выдавать токен вообще бессмысленно, просто проверять имя и токен".

То есть предложение "В моем случае выдавать токен вообще бессмысленно" правильное, а в следующем наверное надо заменить токен на пароль? Тогда всё сойдётся

Answer 1

[Ипатьев]

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

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

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

Верно

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

Comments

[Kolya Vantukh]

Т.е в любом случае нужно возвращать токен при логинизации?

[Ипатьев]

я не вижу, зачем при такой схеме токен.
ну то есть я согласен с вашим же утверждением

при условии верного логина и пароля просто возвращать запрошенные данные - и всё

[Kolya Vantukh]

Роман Юрьевич Ипатьев, то, что хотел услышать. Интересно было, если делать авторизацию без токенов, будет ли это вписываться в стандарты rest

[Ипатьев]

Kolya Vantukh, да мне кажется без разницы.
вообще, я тут подумал, что обычно "несколько раз в день" очень скоро превращается в "несколько раз в минуту".
Так что можно не полениться и сделать всё-таки точку для получения токена по логину и паролю.

[Kolya Vantukh]

Роман Юрьевич Ипатьев, да я тоже порылся на просторах интернета и серьезные дядьки говорят, что передавать логин и пароль при каждом запросе( HTTP Basic authentication) не есть хорошо в плане безопасности, поэтому все таки нужно будет прикручивать jwt)

[Ипатьев]

А при чем здесь HTTP Basic authentication?
И на самом деле надо внимательнее смотреть на даты. Все эти дядьки все жили в прошлом веке. Никакой проблемы с HTTP Basic authentication сейчас нет, ну кроме того что она здесь не нужна.

[Kolya Vantukh]

Роман Юрьевич Ипатьев, я узнал, что есть 3 базовые способы аутентификации для rest: HTTP Basic authentication, token(jwt) и oauth2. Из этого всего, мне больше всего вроде первый подходит, разве нет?

[Ипатьев]

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

Basic, по сути, будет то же самое, только передавать логин и пароль не в данных а в НТТР заголовке, который потом еще парсить надо будет.
а oauth2 это не совсем в ту степь

[Kolya Vantukh]

Роман Юрьевич Ипатьев, все таки сделаю jwt, вы правильно заметили, что запросов в перспективе может быть больше чем несколько в день.
А почему oauth2 это не совсем в ту степь? Разве его суть не в том, чтобы выдавать ключи доступа к апи сторонним приложениям?(если в двух словах). Или я не правильно понимаю?

[Ипатьев]

Kolya Vantukh, в этом, но вашему-то приложению от этого какая печаль?
ну будет выдавать вам токен не сама точка, а какой-то третий сервис? по сути же всё то же самое - отправили пароль, получили токен, с токеном пошли за инфой.

[Kolya Vantukh]

Роман Юрьевич Ипатьев, ну да, для конкретно этого сервиса это не совсем нужно. Просто в будущем на том же сервисе будут еще как минимум 2 отдельных апи(для SPA и апи для клиентов) и думаю, что возможно лучше будет реализовать oauth2 для авторизации. Чтобы для всех 3 апи был одинаковый принцип

Answer 2

[DollyPapper]

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

Comments

[Ипатьев]

на сессиях?

[DollyPapper]

Роман Юрьевич Ипатьев, ошибся да, на куках. Исправил, спасибо.

[Ипатьев]

мне кажется у автора вопроса нет клиента, напрямую поддерживающего куки.
и реализация будет сложнее, чем просто посылать логин и пароль

[Евгений]

Роман Юрьевич Ипатьев, а где хранить логин пароль?

[Ипатьев]

Евгений, в каком смысле "хранить"?

[Евгений]

Роман Юрьевич Ипатьев, если я понял вас и автора, то расклад следующий. Нужно, что бы после авторизации, некоторое время был в доступе бэк. Соответственно, предлагается решение, на каждый запрос отправлять пару логин пароль. Значит их нужно где-то хранить, иначе, при релоаде страницы нужно будет заново авторизовываться

[Ипатьев]

Евгений, нет

Answer 3

[Евгений]

SPA или не SPA не в этом суть.
Где собираетесь хранить пару логин-пароль? На клиенте? Безопасно? Думаю, что нет.
Далее, вам следует выбрать один из существующих механизмов авторизации и применить его на проекте. Это могут быть сессии, токены или что-то еще.

Comments

[Ипатьев]

неужели так трудно прочитать вопрос? "Делаю простое апи, простые запросы через к примеру через guzzle"
Где тут "клиент"? Каким местом тут куки?

[Евгений]

Роман Юрьевич Ипатьев, Токсика сложно выключать?

"не SPA", это вам о чем-нибудь говорит, на что-нибудь намекает?
Тред довольно специфически написан. Для меня в нем смешались кони, люди. Если у автора действительно нет клиента в виде фронта, то на этом мои полномочия всё