Обеспечивают ли токены обновления JWT большую безопасность? Где их хранить?

Я постараюсь ответить на все вопросы в вашем вопросе

• Не используйте токены обновления JWT. Используйте непрозрачные токены обновления. Обычно JWT должны иметь очень короткий срок службы. Причина в том, что отменить их может быть невозможно, если у вас нет черного списка.

• Вы можете хранить токены обновления в защищенных файлах cookie HttpOnly. Если вы хотите избежать CSRF и XSS, вы можете разделить токен доступа и сохранить половину в файлах cookie, а другую половину - в localstorage.

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

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

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

Я начну с небольшого мифа с одним из ваших предположений:

LocalStorage явно не подходит для хранения токена обновления, поскольку он не предназначен для использования в качестве безопасного хранилища.

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

Файлы cookie подвержены атакам CSRF, в то время как LocalStorage не так сильно. И LocalStorage, и файлы cookie подвержены атакам XSS (даже файлы cookie httpOnly, поскольку внедренный код может выполнять любую операцию с учетными данными).

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

Поэтому я не вижу никаких проблем с хранением токенов обновления NOR доступа в LocalStorage исключительно с точки зрения безопасности.

Помимо соображений безопасности, вам может потребоваться хранить их в LocalStorage (или в хранилище без файлов cookie) в зависимости от платформы (платформ), на которой вы развертываете развертывание, например: некоторые мобильные платформы не поддерживают файлы cookie.

И наоборот, если вы планируете запускать веб-приложение JS, которое выполняет рендеринг на стороне сервера, вам могут потребоваться файлы cookie, поскольку обычно серверный процесс не имеет доступа к LocalStorage.

Так что вопрос не только в безопасности.

Что касается основной сути вашего вопроса, который я понял как:

Если маркеры доступа подвержены атакам, что делает маркеры обновления полезными, поскольку они тоже должны быть подвержены тем же атакам?

Ты прав. И токены доступа, и токены обновления могут быть скомпрометированы. Вопрос в том ... что ваш сервер может с этим поделать, когда узнает?

Идея токенов доступа и токенов обновления заключается в том, что токены доступа недолговечны, а токены обновления - долгоживущие.

Лично я не вижу особой пользы в токенах обновления, если только вы не используете JWT в качестве токена доступа, что вы и уклонились в своем сообщении.

Как вы, вероятно, знаете, JWT не имеют состояния (хотя вы можете реализовать белые / черные списки, которые сделают их с отслеживанием состояния, но такого рода поражение цели). Поэтому сервер ничего не может сделать, чтобы отключить JWT без сохранения состояния.

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

Таким образом, чтобы получить лучшее из обоих миров, можно использовать JWT с коротким сроком действия (10 минут или около того) с токенами обновления с длинным сроком действия (многие реализации OAuth никогда не истекают токенами обновления).

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