Блог

Я начинаю внедрять систему единого входа на основе JWT (для нескольких одностраничных приложений в одном домене, так что что-то вроде app1.mydomain.com , app2.mydomain.com , auth.mydomain.com ), используя механизмы, описанные в этой статье из Stormpath.

Чтобы защитить мой подписанный токен JWT от атак XSS, я хочу сохранить токен в защищенном (только HTTPS) и HTTP-файлах cookie. Сам SPA получит информацию о пользователе из тела ответа.

Мой главный вопрос заключается в том, как мы можем реализовать функцию «выхода» в JavaScript, поскольку файл cookie по своей конструкции недоступен из кода JS?

Я предполагаю, что мне придется выполнить вызов сервера, который истечет срок действия файла cookie. Есть ли способ сделать это на стороне чистого клиента?

Лучшим способом было бы выполнить очистку на стороне сервера, как уже предлагал пользователь JEY.

_{Кроме того, я хотел немного расширить возможности, чтобы это не соответствовало комментарию.}

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

Это означает, что вы не сохраняете никакой фактической работы, у вас просто возникает нечеткое ощущение, что если вы скомпрометированы XSS, по крайней мере, токен безопасен.

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

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

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

Учитывая, что вы упомянули несколько приложений в дочерних доменах, следует помнить о следующем:

При авторизации на основе токенов вам предоставляется выбор, где хранить JWT. Обычно JWT размещается в локальном хранилище браузера, и это хорошо работает в большинстве случаев использования. Следует учитывать некоторые проблемы с хранением JWT в локальном хранилище. В отличие от файлов cookie, локальное хранилище изолировано от определенного домена, и к его данным не может получить доступ ни один другой домен, включая поддомены.

(выделено мной, источник: Где хранить токены? раздел Cookies vs Tokens: окончательное руководство)

(Раскрытие информации: я инженер Auth0.)