JWT с SPA без сервера - PullRequest
Новая
       39

JWT с SPA без сервера

0 голосов
/ 19 октября 2018

Приложение представляет собой SPA, который размещается в статическом хранилище (концептуально похожем на S3, хотя это не S3) и вообще не имеет внутреннего сервера.Предположим, это https://static.example.com/app.html

Когда пользователи посещают страницу, они могут проходить аутентификацию у внешнего поставщика, такого как Auth0 и Azure AD.Они завершают процесс аутентификации и отправляются обратно в SPA с id_token на фрагменте URL.Например, https://static.example.com/app.html#id_token=XX.То, что id_token используется для вызова внешнего сервера API, передается в заголовке авторизации Bearer.

Проблема в том, где хранить JWT на клиенте.

  1. Этоизвестный факт, что хранение JWT в sessionStorage может привести к краже токенов с помощью XSS-атак (или добавления вредоносного кода в зависимость и т. д.).
  2. Рекомендуемый подход - хранение JWT в cookie-файле.для него установлено значение HttpOnly или, по крайней мере, его часть (см. раздел «Разделение файла cookie»).Тем не менее, в моем случае это невозможно, так как нет внутреннего сервера, и после аутентификации пользователи перенаправляются непосредственно в SPA, поэтому я не могу создать файл cookie HttpOnly.Вариант этого метода - то, что OWASP рекомендует : использование «cookie-файла отпечатка пальца».Это имеет те же проблемы, так как я не могу установить cookie, который является HttpOnly.
  3. Другой подход, как, например, предложенный в документации Auth0 , заключается в том, чтобы сохранить JWT в памяти,Хотя это должно предотвратить кражу при большинстве (если не во всех?) XSS-атаках, это нецелесообразно, поскольку сеанс будет ограничен текущей вкладкой и не выдержит перезагрузки страницы.

Я вижу две разныеварианты, все с серьезными или потенциально серьезными недостатками:

  1. Сохраните токен в sessionStorage в любом случае, принимая на себя риск того, что в случае атак XSS (или злонамеренная зависимость, введенная через NPM) может привести к сеансамбыть украденнымЭто можно уменьшить, установив короткую продолжительность жизни токенов (например, 1 час).Хотя приложение, над которым я работаю, не хранит критически важную информацию (не банковское или подобное), ошибка в коде, позволяющая украсть сессии через XSS, была бы не очень приятной.
  2. Реализация внутреннего серверапереместить поток аутентификации туда, возможно, даже полностью заменив JWT токенами сеанса.Однако это сделало бы приложение не статичным, и это нежелательно.
  3. (третий вариант, сохранение JWT в памяти, исключен из-за плохого взаимодействия с пользователем)

Чего мне не хватает?

1 Ответ

0 голосов
/ 20 октября 2018

Безопасность - это компромисс - вы можете принять на себя риск XSS, или взять на себя нагрузку на бэкэнд-сервер для большей безопасности, или пожертвовать пользовательским интерфейсом для уровня безопасности, вероятно, между ними.У вас не может быть всего.

Одним из обычных решений является использование очень короткоживущих токенов в sessionStorage и файл cookie httpOnly для провайдера идентификации, чтобы получить новый токен при необходимости.Таким образом, кража токена сеанса обеспечивает меньшую ценность для злоумышленника, и, поскольку XSS требует взаимодействия с пользователем, иногда злоумышленнику может быть трудно получить новый (или легко, в зависимости от того, где находится XSS).Также это решение требует более аккуратной обработки ошибок и приводит к несколько более сложному коду.

...