Как защитить API с помощью JWT
Веб-токены JSON (JWT) — это надежный способ защиты API путем встраивания информации о пользователе непосредственно в токены. Они позволяют аутентификация без сохранения состояния, что означает отсутствие необходимости в хранении сеансов на стороне сервера. Это делает их чрезвычайно эффективными для современных распределённых систем и микросервисов.
Основные выводы:
- Структура JWT: состоит из трех частей — заголовка (метаданные), полезной нагрузки (заявления пользователя) и подписи (обеспечивает целостность).
- Преимущества: Улучшает масштабируемость, производительность и упрощает контроль доступа.
- Лучшие практики обеспечения безопасности:
- Всегда используйте HTTPS для передачи токенов.
- Набор короткие сроки годности за жетоны.
- Для хранения используйте файлы cookie HttpOnly, а не localStorage или sessionStorage.
- Регулярно чередуйте криптографические ключи.
- Проверка токенов на каждой конечной точке API, проверяя такие утверждения, как
эксп,исс, иауд.
JWT лёгкие, быстрые и работают на всех платформах, что делает их отличным выбором для защиты API. Однако важно тщательно внедрять их, чтобы избежать распространённых ошибок, таких как неправильное хранение или валидация.
Как защитить свой веб-API с помощью веб-токенов JSON (JWT)
Структура и компоненты JWT
Понимание принципов работы JSON Web Tokens (JWT) — ключ к реализации безопасной аутентификации API. JWT состоит из трёх частей, закодированных в формате Base64Url: заголовка, полезной нагрузки и подписи.
Формат JWT выглядит следующим образом: заголовок.полезная нагрузка.подпись. Каждая часть кодируется отдельно, а затем объединяется точками. Такая структура обеспечивает быструю проверку токена без учёта состояния.
Вот пример JWT:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c Каждая часть играет определённую роль в обеспечении безопасности и функциональности токена. Давайте разберём их подробнее.
Заголовок: Тип токена и алгоритм
The заголовок Содержит метаданные о токене, включая его тип и алгоритм, используемый для подписи. Это небольшой JSON-объект, который выглядит следующим образом:
{ "alg": "HS256", "typ": "JWT" } The ""тип"" поле обычно указывает, что токен является JWT, в то время как ""алг"" Поле определяет алгоритм подписи. Выбор алгоритма напрямую влияет на безопасность токена.
- HS256: использует общий секретный ключ и подходит для внутренних служб.
- RS256: использует пару открытого и закрытого ключей, что делает его идеальным для публичных API и распределённых систем. Закрытый ключ остаётся у эмитента, валидаторам же нужен только открытый ключ.
- ES256: обеспечивает надежную защиту при меньших вычислительных требованиях, что делает его подходящим для мобильных приложений или сред с низким потреблением ресурсов.
Полезная нагрузка: утверждения и метаданные
The полезная нагрузка Именно там хранится фактическая информация. Она содержит "заявления" — заявления о пользователе или других сущностях, а также метаданные для авторизации.
Претензии делятся на три категории:
- Зарегистрированные претензии: Стандартные поля, такие как
исс(эмитент),эксп(истечение срока),суб(тема), иауд(аудитория). - Публичные заявления: Пользовательские поля, зарегистрированные в публичных реестрах IANA.
- Частные претензии: Пользовательские поля, согласованные сторонами с использованием JWT.
Вот пример полезной нагрузки:
{ "sub": "1234567890", "name": "John Doe", "role": "admin", "exp": 1516239022, "iat": 1516235422 } Важно отметить, что полезная нагрузка не зашифровано – он закодирован только в формате Base64Url. Это означает, что любой может расшифровать и прочитать его содержимое. Избегайте хранения конфиденциальной информации, такой как пароли или номера кредитных карт, в полезной нагрузке.
Правильное управление истечением срока действия токенов (эксп) и выдавались по временам (iat) крайне важно для минимизации рисков. Например, внедрение ролевых данных в полезную нагрузку может упростить локальную авторизацию API, особенно в корпоративных средах.
Подпись: целостность токена
The подпись Обеспечивает целостность токена и предотвращает его несанкционированное использование. Он создаётся путём объединения закодированных заголовка и полезной нагрузки с точкой и подписания результата с использованием указанного алгоритма и секретного ключа.
Для HS256, подпись генерируется следующим образом:
HMACSHA256( base64UrlEncode(заголовок) + "." + base64UrlEncode(полезная нагрузка), секрет ) Для RS256, он использует закрытый ключ для подписи и открытый ключ для проверки:
RSASHA256( base64UrlEncode(заголовок) + "." + base64UrlEncode(полезная нагрузка), privateKey ) Когда API получает JWT, он пересчитывает подпись, используя заголовок и полезную нагрузку токена. Если пересчитанная подпись совпадает с подписью в токене, API понимает, что токен не был изменён. Например, если кто-то попытается изменить полезную нагрузку (например, повысить роль пользователя с "пользователя" до "администратора"), проверка подписи завершится неудачей. Это делает JWT с защитой от несанкционированного вскрытия, что гарантирует легкое обнаружение несанкционированных изменений.
Кроме того, подпись подтверждает происхождение токена, добавляя уровень доверия к процессу аутентификации.
| Алгоритм | Тип ключа | Длина ключа | Лучший вариант использования |
|---|---|---|---|
| HS256 | Симметричный | 256 бит | Внутренние службы |
| RS256 | Асимметричный | 2048+ бит | Публичные API |
| ES256 | Асимметричный | 256 бит | Мобильные/низкоресурсные приложения |
Как реализовать безопасность JWT
Защита ваших API с помощью JSON Web Tokens (JWT) подразумевает структурированный подход к созданию, валидации и авторизации токенов. Это включает в себя настройку безопасных конечных точек аутентификации, корректную валидацию токенов и использование утверждений JWT для управления доступом к ресурсам.
Создание и подписание JWT
Первым шагом является создание безопасного сервера аутентификации, который выдаёт токены после проверки учётных данных пользователя. После успешного входа сервер генерирует JWT с информацией о пользователе и подписывает его с помощью криптографического алгоритма.
Вот пример того, как создать и подписать JWT в Node.js с помощью jsonwebtoken библиотека:
const jwt = require('jsonwebtoken'); const token = jwt.sign( { userId: 123, roles: ['admin'] }, process.env.JWT_SECRET, { algorithm: 'HS256', expiresIn: '15m', issuer: 'https://auth.yourapi.com', auditor: 'https://api.yourapi.com' } ); Для внутренних служб, HS256 Это хороший выбор, поскольку эмитент токена и валидатор используют один и тот же секретный ключ. Для публичных API или распределённых систем, RS256 или же ES256 являются лучшими вариантами, поскольку они используют пары открытого и закрытого ключей, что позволяет проводить проверку токенов без раскрытия ключа подписи.
Лучшие практики управления ключами:
- Храните секреты и закрытые ключи в безопасном месте, например, в переменных среды или в системе управления секретами.
- Используйте надежные ключи: не менее 256 бит для HMAC и 2048 бит для RSA.
- Регулярно меняйте ключи.
- Никогда не задавайте секреты жестко в исходном коде.
Такие платформы, как Serverion Обеспечьте безопасное управление ключами и поддержку HTTPS, поддерживая высокопроизводительные и безопасные развертывания API. Однако надлежащие методы обработки токенов по-прежнему имеют решающее значение.
После создания токенов следующим шагом будет их проверка на каждой конечной точке API.
Проверка JWT в API
Каждая конечная точка API, требующая аутентификации, должна проверять входящие JWT для подтверждения их подлинности и целостности. Этот процесс включает в себя извлечение токена, проверку его подписи и проверку его утверждений.
Вот простой пример проверки токена:
try { const decoded = jwt.verify(token, process.env.JWT_SECRET, { algorithms: ['HS256'], auditor: 'https://api.yourapi.com', issuer: 'https://auth.yourapi.com' }); } catch (err) { // Токен недействителен, запрос отклонен } Ключевые моменты проверки:
- Истечение срока действия (
эксп): Гарантирует, что срок действия токена не истек. - Эмитент (
исс): Подтверждает, что токен исходит от вашего доверенного сервера аутентификации. - Аудитория (
ауд): проверяет, предназначен ли токен для вашего API. - Подпись: Проверяет целостность токена, используя указанный алгоритм.
Отклоняйте запросы, если какой-либо этап проверки не пройден, и возвращайте общие сообщения об ошибках, например "Недействительный токен", чтобы не раскрывать подробности процесса проверки.
Настройка логики авторизации
После проверки токена его утверждения можно использовать для обеспечения контроля доступа. Полезная нагрузка JWT часто включает роли и разрешения пользователей, которые помогают определить, к каким ресурсам пользователь может получить доступ.
Управление доступом на основе ролей (RBAC): Добавьте роли пользователей в полезную нагрузку токена во время его создания и проверьте эти роли в промежуточном программном обеспечении API, прежде чем предоставлять доступ к защищённым конечным точкам. Вот пример:
function requireRole(requiredRole) { return (req, res, next) => { const token = req.headers.authorization?.split(' ')[1]; try { const decoded = jwt.verify(token, process.env.JWT_SECRET); if (decoded.roles && decoded.roles.includes(requiredRole)) { req.user = decoded; next(); } else { res.status(403).json({ error: 'Недостаточно прав' }); } } catch (err) { res.status(401).json({ error: 'Неверный токен' }); } }; } Затем вы можете защитить определенные маршруты, потребовав определенные роли:
app.get('/admin/users', requireRole('admin'), (req, res) => { // Доступ к этой конечной точке могут получить только пользователи с ролью администратора }); Для более детального контроля используйте авторизацию на основе разрешений. Включите разрешения в полезную нагрузку токена, например:
""разрешения": ["чтение:пользователей", "запись:сообщений", "удаление:комментариев"] Затем проверьте наличие необходимых разрешений для каждой операции.
Срок действия и обновление токена:
- Используйте короткие сроки действия токенов доступа (например, 15–30 минут), чтобы минимизировать риски в случае компрометации токена.
- Реализуйте токены обновления для более длительных сеансов, что позволит пользователям повторно проходить аутентификацию без необходимости повторного входа в систему.
JWT не сохраняют состояние, то есть вашему API не нужно хранить данные сеанса или обращаться к базе данных для аутентификации, что делает их идеальными для систем с высоким трафиком и распределённых систем. Такой подход повышает масштабируемость и производительность, сохраняя при этом безопасность.
sbb-itb-59e1987
Лучшие практики безопасности JWT
Для обеспечения безопасности ваших API крайне важно внедрить строгие правила создания, проверки и управления веб-токенами JSON (JWT). Эти меры помогут предотвратить уязвимости и защитить ваши системы.
Использовать HTTPS для передачи токенов
HTTPS не подлежит согласованию при передаче JWT. Поскольку JWT в заголовках HTTP представляют собой обычный текст, передача их по незащищённому соединению делает их уязвимыми для перехвата посредством атак типа «человек посередине». Это может предоставить злоумышленникам несанкционированный доступ к вашим API.
В отчёте OWASP за 2023 год было выявлено, что более 60% уязвимостей API были вызваны неправильной аутентификацией или небезопасной обработкой токенов, причём многие проблемы были связаны с небезопасными методами передачи данных. Для решения этой проблемы следуйте следующим рекомендациям:
- Включить сертификаты SSL/TLS на всех серверах, обрабатывающих аутентификацию JWT.
- Перенаправление HTTP-трафика на HTTPS автоматически.
- Используйте надежные наборы шифров и отключите устаревшие протоколы, такие как TLS 1.0 и 1.1.
- Установить заголовки HTTP Strict Transport Security (HSTS) для предотвращения атак понижения версии протокола.
В распределённых системах необходимо обеспечить единообразное применение HTTPS во всех компонентах. Например, Serverion вводит HTTPS в обязательном порядке во всех своих хостинговых решениях для обеспечения безопасности.
Даже в средах разработки избегайте передачи JWT по протоколу HTTP. Несоблюдение этого правила может привести к уязвимостям, которые могут быть перенесены в рабочую среду.
Установите срок действия токена и используйте токены обновления
Краткосрочные токены — простой, но эффективный способ минимизировать риски. Ограничивая срок действия токенов доступа 15–30 минутами, вы уменьшаете время, отведенное злоумышленникам в случае компрометации токена.
Для более длительных сеансов используйте токены обновления. Эти токены, срок действия которых обычно составляет 7–14 дней, позволяют клиентам запрашивать новые токены доступа без необходимости повторной аутентификации. Вот как это работает:
- После входа в систему сервер аутентификации выдает токен доступа и токен обновления.
- Клиент использует кратковременный токен доступа для запросов API.
- По истечении срока действия токена доступа клиент использует токен обновления для получения нового, сохраняя непрерывность сеанса без ущерба для безопасности.
Исследование MojoAuth показывает, что более 80% нарушений API являются результатом ненадлежащего управление токенами, часто с использованием долгоживущих токенов, которые остаются действительными даже после компрометации. Установив срок действия токенов и используя токены обновления, вы можете значительно снизить эти риски.
Безопасное управление ключами и секретами
Безопасность JWT во многом зависит от того, как вы управляете ключами подписи и секретами. Раскрытие этих ключей — будь то в клиентском коде или в системах контроля версий — может подорвать всю вашу систему безопасности.
Лучшие практики хранения
Храните ключи подписи в защищенных системах, таких как Менеджер секретов AWS или же Хранилище HashiCorp, которые предлагают зашифрованное хранилище, ведение журнала и автоматическую ротацию ключей.
"Изучите основные методы безопасного хранения закрытых ключей PKI для предотвращения несанкционированного доступа и обеспечения соответствия отраслевым стандартам"."
- Блог Serverion
Ключевые рекомендации по прочности
Выбирайте надежные случайные ключи, чтобы обеспечить надежную безопасность:
- HS256: используйте ключи длиной не менее 256 бит, идеально для внутренних сервисов.
- RS256: выберите 2048-битные ключи, лучше всего подходящие для публичных API.
- ES256: обеспечивает высокий уровень безопасности благодаря использованию более коротких ключей, что делает его отличным выбором для мобильных приложений.
| Алгоритм | Уровень безопасности | Длина ключа | Лучший вариант использования |
|---|---|---|---|
| HS256 | Высокий | 256-бит | Внутренние службы |
| RS256 | Очень высокий | 2048-бит | Публичные API |
| ES256 | Очень высокий | 256-бит | Мобильные приложения |
Стратегии ротации ключей
Регулярно меняйте ключи подписи, чтобы минимизировать риски. Используйте систему управления версиями, чтобы ваше приложение могло проверять токены, подписанные как текущими, так и предыдущими ключами, при переходе. Такой подход обеспечивает непрерывность обслуживания и повышает безопасность.
Избегайте непосредственного кодирования секретных данных в кодовой базе. Вместо этого безопасно внедряйте их во время выполнения.
Для установок корпоративного уровня такие платформы, как Serverion, предлагают защищенную инфраструктуру с зашифрованным хранилищем и надежным контролем доступа, гарантируя надлежащее управление ключами в глобальных центрах обработки данных.
Распространенные ошибки JWT и способы их исправления
Даже опытные разработчики могут ошибиться в вопросах безопасности JWT. Чтобы обеспечить безопасность своих API, крайне важно избегать этих распространённых ошибок. Эти ошибки могут свести на нет все ваши лучшие практики, которые вы так упорно внедряли, и сделать ваши системы уязвимыми.
Небезопасное хранение токенов
Хранение JWT в localStorage или sessionStorage — рискованное занятие. Такие методы хранения делают токены уязвимыми для XSS-атак (межсайтового скриптинга), что позволяет злоумышленникам украсть токены аутентификации.
Вот как это работает: если злоумышленник воспользуется XSS-уязвимостью, он получит доступ ко всему, что хранится в этих хранилищах браузера. Получив ваш JWT, он сможет выдавать себя за пользователей, получая несанкционированный доступ к защищённым ресурсам. Согласно отчёту OWASP за 2022 год, более 30% уязвимостей API связаны с плохой аутентификацией и управлением токенами, причем небезопасное хранение JWT является основной причиной.
Вместо localStorage или sessionStorage выберите HttpOnly cookie-файлы. Эти файлы cookie недоступны для JavaScript, что значительно снижает риск XSS-атак. Вот краткое сравнение методов хранения:
| Метод хранения | Уровень безопасности | Уязвимость к XSS | Доступность JS | Рекомендуемое использование |
|---|---|---|---|---|
| локальное хранилище | Низкий | Высокий | да | Не рекомендуется |
| sessionStorage | Низкий | Высокий | да | Не рекомендуется |
| Файлы cookie HttpOnly | Высокий | Низкий | нет | Рекомендовано |
Для мобильных приложений используйте безопасные варианты хранения, такие как Связка ключей iOS или же Хранилище ключей Android, которые обеспечивают аппаратную защиту и шифрование конфиденциальных данных.
При настройке файлов cookie HttpOnly убедитесь, что они также отмечены как Безопасный, поэтому они передаются только по HTTPS-подключениям. Для корпоративных сред такие поставщики, как Serverion, предлагают управляемые решения со встроенным управлением SSL, упрощая реализацию безопасной обработки cookie-файлов в вашей инфраструктуре.
Пропуск проверки токена
Безопасное хранение токенов — это только первый шаг. Также необходимо тщательно их проверить. Никогда не думайте, что токен действителен только потому, что он был получен.
Правильная проверка JWT включает два ключевых этапа: проверка подписи а также проверка претензий. Подпись гарантирует, что токен не был подделан, а проверка заявок подтверждает подлинность токена, его действительность и соответствие вашему приложению.
Вот как можно реализовать надежную валидацию JWT в бэкэнде Node.js Express:
const jwt = require('jsonwebtoken'); try { const decoded = jwt.verify(token, process.env.JWT_SECRET, { algorithms: ['HS256'], auditor: 'https://api.example.com', issuer: 'https://auth.example.com' }); req.user = decoded; } catch (err) { return res.status(401).send('Неверный токен'); } В этом примере проверяется подпись токена, алгоритм, аудитория и эмитент, что гарантирует приём только легитимных токенов. Всегда указывайте ожидаемый алгоритм, чтобы злоумышленники не использовали более слабые методы проверки посредством атак, основанных на путанице алгоритмов.
При отклонении недействительных токенов используйте общие сообщения об ошибках. Это не позволит злоумышленникам использовать подробные сообщения об ошибках для совершенствования своих эксплойтов.
Размещение конфиденциальных данных в JWT
Содержание вашей полезной нагрузки JWT так же важно, как и то, как вы её храните и проверяете. Никогда не включайте конфиденциальную информацию в полезную нагрузку JWT. Помните, что полезные нагрузки JWT закодированный, не зашифрован, а это значит, что любой, кто перехватит токен, сможет легко расшифровать его содержимое.
Конфиденциальная информация, такая как пароли, номера социального страхования или данные кредитных карт, ни при каких обстоятельствах не должна быть частью JWT. Если токен перехвачен, зарегистрирован или раскрыт, все эти данные становятся уязвимыми для злоумышленников.
Вместо этого ограничьте полезную нагрузку только важная информация Необходимые для авторизации данные, такие как идентификатор пользователя, роль и стандартные требования, например, срок действия. Для любых дополнительных данных пользователя выполните отдельный вызов API после проверки токена, чтобы безопасно получить их с сервера.
Для дальнейшего повышения безопасности внедрите механизмы отзыва токенов Например, чёрные списки для аннулирования скомпрометированных токенов. Используйте короткие сроки жизни (например, 15-30 минут) для токенов доступа в сочетании с токенами обновления с более длительным сроком действия, чтобы минимизировать риски, связанные с компрометацией токенов.
В корпоративных средах, где с токенами могут взаимодействовать несколько команд и сервисов, эти практики ещё более важны. Такие поставщики, как Serverion, предлагают безопасные инструменты управления ключами и обеспечения соответствия требованиям, помогая организациям поддерживать надёжную защиту JWT во всей своей инфраструктуре.
Ключевые моменты безопасности JWT API
Чтобы обеспечить безопасность ваших API и сохранить функциональность, внедрение безопасности JWT требует комплексного подхода. Благодаря безгражданской природы JWT отлично работают в современных распределенных системах, позволяя API масштабироваться без необходимости управления сеансами на стороне сервера.
Вот на чем вам нужно сосредоточиться:
- Правильная проверка токенов: Всегда проверяйте подпись JWT и основные утверждения, такие как
эксп(истечение срока),исс(эмитент), иауд(аудитория). Это гарантирует подлинность токена и отсутствие подделки. - Используйте короткие сроки службы: Сохраняйте токены доступа действительными в течение короткого периода, обычно 15–30 минут, и объединяйте их с токенами обновления, срок действия которых составляет 7–14 дней. Обеспечьте безопасную ротацию токенов обновления, чтобы снизить риски.
- Безопасная передача и хранение: Всегда передавайте токены по протоколу HTTPS и храните их в безопасном месте, например, в файлах cookie HttpOnly, чтобы предотвратить несанкционированный доступ.
- Безопасное управление ключами: Храните криптографические ключи в безопасных средах, таких как переменные среды или специальные системы управления ключами, чтобы защитить их от раскрытия.
- Используйте заявки для контроля доступа: Используйте утверждения JWT для эффективной реализации управления доступом на основе ролей (RBAC), избегая дополнительных запросов к базе данных. Однако никогда не включайте в полезную нагрузку JWT конфиденциальную информацию, такую как пароли или личные данные, поскольку JWT только кодируются, а не шифруются.
Эти практики составляют основу надежной безопасности JWT. Для организаций, работающих с критически важной инфраструктурой, такие поставщики, как Serverion предлагаем решения по управляемому хостингу со встроенными SSL-сертификатами, безопасным хранилищем ключей и глобальными центрами обработки данных для поддержки безопасной передачи данных по протоколу HTTPS и общей безопасности инфраструктуры.
Часто задаваемые вопросы
Как JWT повышают масштабируемость и производительность API по сравнению с сеансовой аутентификацией?
Веб-токены JSON (JWT) предлагают эффективный способ повышения масштабируемости и производительности API, устраняя необходимость в хранилище сессий на стороне сервера. При традиционной аутентификации на основе сессий серверу приходится хранить данные сессий и выполнять постоянный поиск, что может привести к перегрузке ресурсов. JWT же являются самодостаточными — они содержат всю необходимую информацию о пользователе внутри самого токена. Это сокращает нагрузку на сервер и упрощает масштабирование на несколько серверов, поскольку централизованное хранилище сессий не требуется.
Ещё одним преимуществом JWT является их лёгкая структура, что позволяет легко отправлять их через HTTP-заголовки. Это делает их идеальным решением для современных архитектур API без сохранения состояния. Кроме того, их компактная структура и криптографическая подпись обеспечивают безопасное и эффективное взаимодействие между клиентами и серверами, способствуя бесперебойной работе.
Каковы различия в безопасности между протоколами HS256, RS256 и ES256 для подписи JWT и как выбрать правильный протокол для моего API?
Алгоритм, который вы выбираете для подписи JSON Web Tokens (JWT), играет решающую роль в безопасности вашего API. HS256 использует общий секретный ключ как для подписи, так и для проверки токенов. Этот подход прост, но требует тщательного управления секретным ключом для обеспечения безопасности. С другой стороны, RS256 а также ES256 Используют пары открытого и закрытого ключей, обеспечивая дополнительный уровень безопасности. В этих алгоритмах закрытый ключ используется исключительно для подписи, а открытый ключ распространяется для проверки.
Выбирая алгоритм, учитывайте конкретные потребности и особенности настройки вашего API. Если простота и скорость — ваши главные приоритеты, HS256 Может подойти, если секретный ключ хорошо защищён. Для систем, требующих более высокой безопасности, особенно в распределённых средах, где открытые ключи можно свободно передавать друг другу, RS256 или же ES256 — лучший выбор. Примечательно, ES256 обеспечивает преимущество меньших размеров токенов и надежной криптографической защиты благодаря эллиптической криптографии.
В конечном счете, главное — тщательно оценить свои требования и следовать лучшим практикам управления ключами, чтобы сохранить безопасность вашего API.
Каковы наилучшие практики обработки истечения срока действия токенов и обновления токенов, чтобы обеспечить безопасность и при этом сохранить бесперебойную работу пользователей?
Для эффективного управления истечением срока действия токенов и их обновления необходимо найти правильный баланс между обеспечением безопасности и обеспечением бесперебойной работы пользователей. Токены доступа Должны иметь короткий срок службы, чтобы ограничить потенциальный ущерб, если попадут не в те руки. В то же время вы можете использовать токены обновления генерировать новые токены доступа после истечения срока действия текущих, что позволяет пользователям реже входить в систему.
Храните токены обновления безопасно — HTTP-файл cookie — хороший вариант для минимизации риска кражи. Также важно иметь системы обнаружения и отзыва скомпрометированных токенов. Это может включать в себя мониторинг использования токенов или ведение чёрного списка недействительных токенов. Сочетание краткосрочных токенов доступа с тщательно управляемыми токенами обновления помогает обеспечить высокий уровень безопасности, не создавая неудобств для пользователей.
