1.) Если апи используется тем же сервисом на котором он же и расположен можно ли хранить access_token у юзера в куках для обращения к rest api? Типо есть на бэкенде обычный Веб-апликейшин, какая-то его часть restful, есть клиентсайд, которому нужно по токену обращаться к rest api, т.к. токен нужно где-то сохранять на клиенте (ну не в оперативной же памяти, которая даунится с перезагрузкой страницы), а это в большинстве случаев куки. Если рест апи это сторонний сервер к которому мы обращаемся своим монолитным приложением, то естественно рестапи не хранит и не должен никаких состояний, а если рест апи обособленная часть нашего апликейшина? Которая, возможно, помимо сайта будет обслуживать и мобайл-апликейшин.
2.) Если передавать токен в куки при регистрации/авторизации, то как избежать logout'а при входе с другого браузера/устройства, если при входе токен в базе пользователя будет переписан?
Всем, в заранее, большое спасибо и низкий поклон :3
Токен в базе хранить не нужно. REST совсем не для этого придуман. Никаких сессий в базе! Токен генерить по отработанному стандарту JWT и хранить там всю нужную информацию о юзере. На клиенте грамотно использовать localStorage/ sessionStorage (разные ющера на разных таба!) и цеплять в хидер authorization на каждый запрос к api
Сессия пользователя полностью контролируется expiry в токене и валидируется без обращения к базе.
Сделать таблицу токенов с ссылкой на юзера или приложени. Тогда можно держать не один токен для каждого пользователя
Делал систему авторизации с примерно такой таблицей
id
token
type_of_token
user_id
app_id
token генерировался от юзернейма с примесью пароля, чтобы скинуть все токены, при замене пароля. type_of_token указывал для чего был сгенерирован токен(для прямого общения с юзером или с приложением) ну и ссылки на юзера в другую таблицу и ссылка на приложение, если для приложения генерировалось.
Токен хранить в куках нормально. Главное для всех важных действий надо его дописывать куда-то в данные POST формы или в GET запрос и последующей проверкой на сервере для безопасности CSRF.
FireGM: просто я думал есть лаконичней решение, если у меня на каждого из миллиона пользователей будет по 4 токена то такие циклы уже будут напрягать сервер
Stopy: Во-первых, вы сначала найдите этот миллион юзеров и тогда наймите специалистов. Во-вторых даже если будет десятки миллионов юзеров, можно запускать скрипт в не сильно нагрузочное время. В третьих, при таком количестве уже используется кэш и без разницы что там делается с бд, можете вообще не стандартную бд для этого использовать, а тарантул, например.. Не надо преждевременно оптимизировать.
