а если между серверами?
Можно в и кеше, в оперативке, в БД
Если речь идёт о вебе то с точки зрения безопасности и для защиты от многих типов атак любые данные которые идентифицируют клиента (токен, ид сессии и тд) должны храняться в секюреых куках типа http only, после авторизации браузер сохранит данные у себя и с каждым запросом отправлять на сервер, причём доступ к этим данным js получить не может, тк все работает автоматически то никакие клиенты не нужны
Cookie подход облегчает клиенту, так как браузер отправляет куки автоматически по соответствию хоста. Хотя, для того же Angular http клиента, вроде как, нужно было явно при формировании запроса указать, что credentials true, вроде бы. И на сервере нужно CORS + CSRF подключать для безопасности при Cookie подходе
в любом случаи, если мы говорим про Angular нужен перехватчик запросов чтобы дополнить запрос данными авторизации, это или токен или credentials или что то еще, поэтому это неважно, а что на на счет безопасности надо понимать что есть разные уровни, причем на сервере и на клиенте они разные, куки закрывают вопрос доступа к чувствительным данным, то есть не один код не сможет получить доступ к ним, а CORS + CSRF это другая тема, например если мы делаем SPA на REST то все ровно надо включить CORS и настроить, в некоторых проектах CORS подтверждает запросы с любого домена потому что это публичный API а CSRF редко где в SPA можно использовать, и повторюсь мы сейчас говорим о безопасности на клиенте и на сервере, куки это инструмент для того чтобы не допускать утечку данных с сайт-клиента а CORS + CSRF это уже верификация на сервере, но если злоумышленник не может получить доступ к кукам его дальнейшие действия бесполезные
Я с Вами не спорю, все так
не воспринимайте мои слова как критику 🙂 просто поделился информацией
Обсуждают сегодня