Жетоны безгражданства и хранения

Question

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

Другие отмечают сохранение фактического токена в виде файла cookie httpOnly с меньшим риском.

Мои вопросы:

• Как это считается лицом без гражданства? особенно с масштабируемостью и потенциальным использованием балансировщиков нагрузки.
• Есть альтернативы, кэш-память и хранилища базы данных? Это чем-то отличается от сессий?
• В случае SPA, как сохранить помните меня функциональность?

Answer 1

Аси Кавинду написала, localStorage - хорошее место. Если вы хотите защитить приложение от XSS-атак, используйте Content Security Policy , чтобы браузер выполнял только ваш код JavaScript. Недавно был опубликован RFC о лучших практиках для OAuth 2.0 и приложений на основе браузера , поэтому вы можете проверить его.

Если вы хотите сохранить состояние (сеанс) на своем бэкэнде с несколькими бэкэнд-узлами (кластером), вы можете использовать некоторое общее хранилище данных, такое как база данных или Hazelcast. Архитектура имеет состояние так же, как и один внутренний узел с сеансом в памяти.

Если у вас есть сеанс на вашем бэкэнде и cookie, вам больше не нужен токен доступа, так как ваш SPA вызывает только ваш бэкэнд, и токен будет служить той же цели, что и идентификатор сеанса из куки.

Функциональность "помни меня" может быть реализована с помощью файла cookie либо у вашего провайдера аутентификации (возможно, лучший выбор с точки зрения безопасности), либо в вашем собственном приложении.

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

Answer 2

Поддержка сеанса применима только в том случае, если в вашем приложении есть бэкэнд. С точки зрения чисто SPA хранение токена в localstorage является приемлемым и относительно безопасным. Современные браузеры имеют возможность защитить loaclsotrage по сравнению с другими средствами.

Если у вас есть серверная часть, лучше сопоставить токен доступа с сеансом, чем сохранять его в файле cookie. Также одно преимущество, которое вы получаете с этим, - это возможность получить токен обновления, который можно сохранить в бэкэнде.

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

Помните, что функциональность - это снова нечто, созданное с помощью куки. Это функциональность, предоставляемая сервером авторизации. Думайте об этом как о вашем браузере, который запоминает статус вашего Facebook. Он использует куки, и ваше приложение не должно беспокоиться об этом.