Детальный анализ JWT

задняя часть Безопасность браузер XSS

1. Жетон

токен представляет собой строку строк, обычно потому, что он используется в качестве учетных данных аутентификации, наиболее распространенным сценарием использования является аутентификация API.

1. API-аутентификация

Итак, каковы общие методы аутентификации API? Я примерно рассортировал это следующим образом:

cookie + session

Тот же метод аутентификации, что и обычный веб-вход, очень распространен и не будет повторяться здесь.

HTTP Basic

Объедините учетную запись и пароль и добавьте в заголовок кодировку base64. Очевидно, что поскольку номер счета и пароль передаются практически «открытым текстом», и каждый запрос передается, безопасность можно себе представить.

HTTP Digest

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

Но на самом деле самая большая проблема: каждый запрос должен брать сводку учетной записи и пароля, то есть каждый запрос должен иметь учетную запись и пароль, то есть учетная запись и пароль либо кэшируются, либо идут на каждый запрос, пользователь должен ввести пароль один раз, что явно неуместно. Опять же, та же проблема существует с описанным выше Basic.

Token

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

Итак, каковы преимущества токена по сравнению с методом аутентификации Cookie + Session?

2. Преимущества токена

По сравнению с Cookie + Session преимущества токена в основном включают следующие два:

CSRF-атака

Этот принцип не будет введен. Причина этой атаки заключается в том, что в методе аутентификации Cookie + Session данные аутентификации (session_id в cookie) автоматически переносятся браузером и отправляются на сервер. С помощью этой функции злоумышленник Вы можете добиться эффекта атаки, позволив пользователю по ошибке щелкнуть ссылку атаки. Токен добавляется в запрос в качестве динамического параметра с помощью собственной логики клиента, и токен не будет легко утекать, поэтому у токена есть естественное преимущество в защите от CSRF.

Подходит для мобильных приложений

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

3. Типы токенов

Вообще говоря, существует три основных типа токенов:

  • Пользовательский токен: токен, настроенный разработчиком в соответствии с бизнес-логикой.
  • JWT: JSON Web Token, спецификация токена, определенная в RFC 7519.
  • Oauth2.0: спецификация авторизации, определенная в RFC 6750, но на самом деле это не токен, но в нем тоже есть польза

Выше я подробно описал часто используемые методы аутентификации для API и преимущества токенов по сравнению с cookie + session. Затем внимательно проанализируйте JWT.

2. Состав и преимущества JWT

JWTполное имяJSON Web Tokens, является нормализованным токеном. Его можно понимать как набор спецификаций для технологии токенов, которая находится в разработке.RFC 7519предложено в.

1. Состав

Токен JWT — это строка, состоящая из трех частей: заголовка, полезной нагрузки и подписи..разделены, например:xxxxx.yyyyy.zzzzz

заголовок

Заголовок обычно состоит из двух частей: типа токена (например, JWT) и используемого алгоритма подписи (например, HMAC SHA256 или RSA). Например:

{
  "alg": "HS256",
  "typ": "JWT"
}

затем используйтеBase64UrlКодирование для получения заголовка, т.е.xxxxx.

Полезная нагрузка

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

Свойства нагрузок также делятся на три категории:

  • Предопределенный (зарегистрированный)
  • публичный
  • частный

предопределенная нагрузка

{
  "sub": "1",
  "iss": "http://localhost:8000/auth/login",
  "iat": 1451888119,
  "exp": 1454516119,
  "nbf": 1451888119,
  "jti": "37c107e4609ddbcc9c096ea5ee76c667",
  "aud": "dev"
}

Первые 7 полей здесь все официально определенные, то есть предопределенные (Зарегистрированные претензии), не все из них обязательны.

  • iss (эмитент): Эмитент
  • суб (тема): тема
  • aud (аудитория): аудитория
  • exp (время истечения): время истечения
  • nbf (не раньше): время действия, до этого недействительно
  • iat (выпущено в): выдано в
  • jti (идентификатор JWT): номер

общедоступная полезная нагрузка

Дополнительные полезные нагрузки, которые можно определить при использовании JWT. Во избежание конфликтов следует использоватьIANA JSON Web Token Registryопределенный в , или добавьте к дополнительным полезным данным уникальный идентификатор, аналогичный пространству имен.

частная полезная нагрузка

Это разновидность полезной нагрузки, которая согласовывается между двумя сторонами информационного обмена и не является ни предопределенной полезной нагрузкой, ни общедоступной полезной нагрузкой. Этот тип полезной нагрузки может конфликтовать и должен использоваться с осторожностью.

поставить вышеjsonпровестиBase64UrlКодирование получает полезную нагрузку, т.е.yyyyy.

Понимание нагрузки:

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

Например, вы определяетеadminПолезная нагрузка, которую следует классифицировать как частную полезную нагрузку, может конфликтовать с данными, определенными другими. Но если вы добавите префикс (пространство имен), напримерnamespace-admin, то это следует считать общедоступной полезной нагрузкой. (Но на самом деле стандарт не определяет, как объявлять пространства имен, поэтому, строго говоря, конфликты все же могут быть)

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

Подпись

При подписании вам нужно использовать две ранее закодированные строки.Если вы начинаете сHMACSHA256Шифруется следующим образом:

HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    secret
)

после шифрованияbase64urlКонечная строка, полученная путем кодирования,tokenтретья частьzzzzz.

комбинация, чтобы получитьtoken：xxxxx.yyyyy.zzzzz.

Роль подписи: чтобы гарантировать, что JWT не был подделан, принцип заключается в следующем:

Алгоритм HMAC является необратимым алгоритмом, похожим на MD5 и хеширование, но с еще одним ключом.Ключ (то есть секрет выше) хранится на сервере.После того, как клиент отправит токен на сервер, сервер может отправить заголовок и Полезная нагрузка и секрет, совместно используемые заранее, снова выполняют шифрование HMAC, и полученный результат сравнивается с третьим абзацем токена.Если то же самое, это указывает на то, что данные не были подделаны.

Hash-based Message Authentication Code

2. Используйте

Есть два способа использования JWT:

  • Добавить к URL:?token=你的token
  • Добавьте в шапку, рекомендуется использовать это, т.к. это более безопасно в случае с https:Authorization:Bearer 你的token

Есть три способа сохранить JWT на стороне клиента:

  • LocalStorage
  • SessionStorage
  • Cookie [Невозможно установить только HTTP]

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

Поскольку HTTPonly не включен, вам следует обратить внимание на предотвращение уязвимостей XSS.

Междоменная политика для файлов cookie

Сын может читать отца, но отец не может читать сына, а братья не могут ходить друг к другу в гости.

a.xxx.comиb.xxx.comможет читатьxxx.com,ноa.xxx.comиb.xxx.comне умеют читать друг друга,xxx.comне могу читатьa.xxx.comиb.xxx.comиз.

Вы можете подумать: сохраните куки, разве я снова не стану такой же, как куки + сессия?

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

3. Преимущества перед обычными токенами

Поскольку JWT также является токеном, какие у него преимущества перед обычными токенами?

нет статуса

Поскольку срок действия JWT — это полностью время истечения срока действия, закодированное в его полезной нагрузке, сервер не поддерживает никакого состояния, поэтому JWT «вообще» является «безгражданским» (почему оно вообще, мы поговорим об этом позже). Самое большое преимущество безгражданства заключается в трех моментах:

  • Сохранение ресурсов сервера: поскольку серверу не нужно поддерживать состояние, он может сохранять ресурсы, изначально потраченные сервером на сохранение этих состояний.
  • Подходит для распределенных: поскольку серверу не нужно поддерживать состояние, поэтому, если сервер представляет собой распределенный кластер, состоящий из нескольких серверов, нет необходимости синхронизировать их состояния друг с другом, как «с сохранением состояния».
  • Время для места: поскольку проверка токена выполняется посредством проверки подписи, проверка подписи потребляет время ЦП, а «с сохранением состояния» требует запроса существующего состояния сервера с помощью учетных данных, предоставленных клиентом, что потребляет I/ O и память и место на диске. Обычно для веб-службы требуется интенсивный ввод-вывод, поэтому, изменив время для пространства, можно улучшить общее использование оборудования.

закодированные данные

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

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

Таким образом, JWT имеет четыре преимущества:

  • Анти-CSRF
  • Подходит для мобильных приложений
  • нет статуса
  • закодированные данные

Первые два — преимущества токенов, а последние два — уникальные преимущества JWT.

3. Проблемы безопасности JWT

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

1. Переиграть атаку

Атака с повторным воспроизведением — это средство атаки путем однократного воспроизведения исходного пакета. Должно быть ясно, что cookie + сессия также имеет проблему повторной атаки.

Обычно используемые меры для предотвращения повторных атак следующие:

timestamp

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

Эта стратегия соответствует JWT, которая заключается в установке более короткого периода действия токена.

nonce

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

Эта стратегия соответствует JWT, которая устанавливает черный список для токена, но не устанавливает срок действия.

timestamp + nonce

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

Эта стратегия соответствует JWT, которая заключается в установке как черного списка, так и срока действия токена.

вызов-ответ

На самом деле это иtimestamp + nonceСтратегия такая же, за исключением того, что случайная строка генерируется сервером для клиента, и клиент запрашивает случайную строку, предоставленную сервером. Какая от этого польза? Сервер может сгенерировать эту строку с помощью алгоритма шифрования, чтобы она была связана с отметкой времени, и клиент не мог ее подделать. Это избавляет от необходимости вести черный список. Это также стратегия «время-в-пространстве». Но очевидно, что выполнять предварительный запрос каждый раз или несколько раз для получения случайной строки не особенно удобно, и возникающее дополнительное потребление также необходимо учитывать.

серийный номер

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

HTTPS

Окончательное решение, HTTPS, будет автоматически поддерживать неявный серийный номер во время процесса рукопожатия, что само по себе решает проблему сохранения серийного номера.

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

2. Токен украден

Поскольку токен содержит статус входа в систему, как только токен будет украден, личность будет украдена. Тогда меры профилактики токенов от кражи распределяются следующим образом:

  • Использование транспорта HTTPS: устранение неполадок с точки зрения транспортного уровня
  • HTTPOnly: решите проблему с точки зрения уровня хранилища, чтобы предотвратить атаки XSS от кражи файлов cookie, но у этого решения действительно есть проблемы, потому что js не может прочитать токен и добавить его в заголовок. Поэтому, если вы не включаете HTTPOnly, вы должны уделить особое внимание предотвращению XSS-атак.
  • Встроить отпечаток клиента в токен: с отпечатком клиента, даже если хакер украдет ваш файл cookie, он не сможет сделать запрос с вашим файлом cookie.
  • Установите более короткий срок действия токена: чтобы в случае кражи токена его нельзя было использовать по истечении определенного периода времени.

4. Другие проблемы с JWT

Помимо проблем безопасности, JWT должны учитывать множество других проблем.

1. Проблема с выходом из системы

Поскольку JWT не имеет состояния, срок его действия полностью определяется им самим, а это значит, что сервер не может аннулировать токен. Очевидно, что это более серьезная проблема, и для нее есть много решений:

1.1 Клиент активно выходит из системы

Клиент напрямую удаляет файл cookie, в котором хранится токен.

Эта схема самая простая, результатом операции является то, что ни у клиента, ни у сервера нет этого токена, но проблема в том, что этот токен на самом деле не непригоден, а находится в свободном состоянии.

Политика черного списка

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

Будет ли эта стратегия иметь проблему слишком большого черного списка?

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

1.2 Активный выход из сервера\пользователя для смены пароля

Хранить токен и uuid в Redis как пару ключ-значение

Это решение кажется не проблематичным, но на самом деле оно эквивалентно реализации cookie + сеанса, JWT теряет функцию «без сохранения состояния», а также теряет ряд преимуществ, предоставляемых функцией «без сохранения состояния».

Пусть у каждого пользователя будет секрет

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

Эта стратегия звучит так, будто вам не нужно поддерживать состояние, но на самом деле есть более серьезные проблемы. Только представьте, первое решение — найти токен для выхода по uuid в таблице токенов вошедшего в систему пользователя. Cookie+session заключается в том, чтобы найти соответствующий сеанс в таблице сеансов вошедшего в систему пользователя через session_id и удалить его, чтобы выйти из системы. И эта схема состоит в том, чтобы выйти из системы, найдя секретную модификацию для uuid у всех пользователей (не вошедших пользователей). Это кажется менее эффективным, поскольку диапазон поиска больше.

предварительный черный список

Uuid пользователя, подлежащего отмене, и текущее время (TIME) формируются в пару ключ-значение и добавляются в пречерный список.При следующем запросе, если uuid соответствует черному списку и время выдачи раньше ВРЕМЯ, оно будет отменено. . Таким образом, область поиска предназначена для пользователей, срок действия которых еще не истек, но которые хотят выйти из системы. И с точки зрения логики реализации этот предварительный черный список можно сделать вместе с черным списком сигнатур.

Дополнение к политике черного списка:

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

Количество пользователей или токенов, срок действия которых не истек, но которые будут досрочно отключены

"

Видно, что стратегия «черного списка» может эффективно решить проблему выхода из JWT.

2. Проблемы с продлением

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

web

Если нет запросов более определенного периода времени, вам необходимо снова войти в систему, это время обычно устанавливается на 1-2 часа.

app

Если долго нет заявки, нужно авторизоваться заново, это время обычно 15-30 дней

Как можно выполнить это требование?

2.1 Метод 1

  • Сервер берет на себя обновление
  • токен устанавливает «время истечения срока действия»
  • После истечения срока действия токена его все еще можно обновить, когда он все еще находится в пределах «времени обновления».
  • После истечения срока действия токена его нельзя обновить по истечении «времени обновления», и вам необходимо снова войти в систему.

web

Предполагая, что время выдачи токена 12:00, а спрос 2 часа, необходимо снова войти в систему, не делая запроса. Тогда время истечения составляет 1 час, а время обновления — 3 часа.

Затем его можно использовать в обычном режиме с 12:00 до 13:00.Если запрос сделан с 13:00 до 15:00, сервер автоматически изменит новый токен клиенту для продления.

Если между 13:00 и 15:00 нет запроса, но запрос сделан после 15:00, он считается просроченным и вам необходимо снова войти в систему.

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

app

Как и в случае с веб-сайтом, вы можете установить более длительный период времени.

Есть одно предостережение для разработчиков, работающих с Laravel и использующих плагин tymon/jwt-auth.

Обновление токена здесь не черезrefreshЭта операция получает новый токен, так как токен достигнет предела времени обновления в процессе непрерывного обновления. Приведенная выше логика заключается в том, чтобы каждый раз выпускать новый токен, пока вы продолжаете подписывать, вы можете использовать его все время. Затем старый токен здесь помещается в черный список, а срок действия черного списка устанавливается на «время обновления» — 3 часа.

Конечно, если разработчик считает, что использовать его постоянно нехорошо, он может установить более длительное время обновления и использоватьrefreshОперация по получению нового токена и время обновления гарантируют, что после каждого входа в систему для получения токена, даже если обновление будет своевременным, время обновления не превысит время обновления.

Затем здесь появится новая яма:

Если время обновления установлено на 14 дней, срок действия устанавливается на 2 часа.

Токен A обновляется для получения токена B, когда «

Итак, если вы хотите использоватьrefreshвремя обновления должно быть наименьшим кратным времени истечения срока действия.

2.2 Метод 2

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

web

Предположим, токен выпущен в 12:00, а спрос составляет 2 часа до истечения срока его действия без запроса. Затем установите период действия на 2 часа, нет необходимости устанавливать период обновления. Затем каждый запрос будет заменять токен новым токеном. Если в течение 2 часов не будет выполнено ни одного запроса, срок действия токена, полученного в результате последнего запроса, истечет, и вам потребуется снова войти в систему. То же самое можно использовать в течение длительного времени, если вы продолжите подписывать.

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

app

Как и в случае с веб-сайтом, вы можете установить его на более длительное время.

Затем настало время вопросов:

  1. Как влияет на производительность постоянное обновление токена?

    Раньше каждый запрос требовал проверки подписи токена, но теперь должен быть выдан новый токен и выполнена операция подписи, поэтому количество операций изменяется с n до 2n.

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

  2. Токен обновляется каждый раз. Будет ли успешным только один запрос из-за обновления токена во время параллельных запросов?

    Ответ заключается в том, что это вызывает эту проблему, как ее решить? Установите льготное время. После каждого обновления токена исходная логика должна быть немедленно недоступна. Теперь установите льготное время, чтобы сделать ее доступной в течение n секунд.

Короче говоря, эта стратегия приведет к удвоению затраченной операции ЦП и приведет к огромному черному списку, а затем необходимо установить льготный период для решения проблемы одновременных запросов, Что касается того, принесет ли льготный период проблемы с безопасностью, это незначительно. .

2.3 Решения по расширению черного списка

Как было сказано выше, для метода 1 [ограничения не могут продлеваться все время] это приведет к огромному черному списку, а для метода 2 это всегда приведет к еще большему черному списку. Есть ли решение? Есть конечно.

Мы можем думать об этом таким образом, поскольку токен был обновлен, время выпуска до этого обновления можно считать недействительным. Таким образом, аналогично описанной выше стратегии «до внесения в черный список», вместо добавления токена в черный список при обновлении я добавляю uuid-refresh_time в пару ключ-очистка и добавляю его в черный список. черный список изменится с N на один.

Но есть еще одна проблема, которую следует учитывать: пользователь открывает два браузера и входит в одну и ту же систему в разное время (при условии, что это разрешено бизнесом), тогда обновление токена в одном браузере может привести к входу в другой браузер. . Следовательно, значение ключа, хранящееся в черном списке, должно быть дополнено ключом для представления каждого входа в систему, и этот ключ должен быть унаследован при обновлении полезной нагрузки JWT.

Исходя из вышеописанной оптимизации, размер черного списка стал таким: сумма количества систем, зашедших в систему каждым пользователем одновременно, становится такой же, как куки + сессия.

Например, в системе A (при сроке действия 2 часа, времени обновления 14 дней) вы входите в свою учетную запись с помощью браузера, я вхожу в свою учетную запись с помощью браузера Chrome, а затем я снова вхожу в свою учетную запись с помощью браузера QQ. , то размер черного списка: 1 + 2 = 3

Для способа 1 [ограничения не могут продлеваться постоянно], размер черного списка (максимум): 168+168*2

Для метода 2 размер черного списка: сумма количества запросов x в течение 2 часов, количества запросов y в браузере Chrome и количества запросов z в браузере QQ, а именно : х + у + г

2.4 Резюме

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

3. Нужно ли каждый раз обновлять токен?

Давайте сначала перечислим преимущества и недостатки каждого токена обновления:

преимущество:

  • Возобновляемый
  • Возможность разрешить повтор
  • безопаснее

недостаток:

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

Как обсуждалось выше, как «обновление», так и «воспроизведение» могут быть решены другими способами. Только "безопаснее" - половина болевой точки, почему это половина болевой точки? Потому что при использовании HTTPS есть всего несколько способов украсть токены:

  • Взлом HTTPS
  • Скопируйте его прямо с вашего компьютера
  • XSS [Как упоминалось ранее, чтобы разрешить чтение js, нельзя установить HTTPOnly]

Только третий способ имеет небольшую вероятность.

Поэтому либо обновлять каждый раз, либо выбирать в соответствии с конкретной бизнес-ситуацией.

5. Для чего подходит JWT?

1. RESTful API без сохранения состояния

Этот явно подходит.

2. Единый вход SSO

Должен быть реализован единый вход:

  • Управление сеансом: решается путем внесения в черный список и предварительного внесения в черный список.
  • Продление: разрешено подписанным решением

Видно, что развертывание некоторой дополнительной логики (черный список, управление продлением) в JWT может заставить JWT заменить cookie + сеанс в большинстве сценариев.

6. JWT и Oauth2.0

Я не буду вдаваться в подробности о том, что делает Oauth 2.0, на самом деле он не на том же уровне, что и JWT. Oauth2.0 — это удобная сторонняя спецификация авторизации, а JWT — спецификация структуры токена. Просто JWT часто используется для аутентификации при входе, а Oauth2.0 также предполагает вход в систему при авторизации, поэтому его проще запутать.

Но здесь я говорю, что Oauth 2.0 действительно можно использовать с JWT.

Ниже приведен общий возврат входа в систему Oauth2.0:

{
    "access_token":"kag2geh11a3eh56e23hj",
    "expires_in":7200,
    "refresh_token":"jgko97cq4c8wn69j",
    "scope":"SCOPE" 
}

В Oauth2.0,access_tokenиспользуется для запросов данных иrefresh_tokenобновитьaccess_token. При каждом обновлении предыдущий access_token будет недействительным, иaccess_tokenиrefresh_tokenОчевидно, что состояние не записывается, поэтому состояние должно сохраняться для сервера.

После объединения JWT и Oauth2.0 вы можете получить следующий результат:

{
    "access_token":"xxx.yyy.zzz",
    "expires_in":7200,
    "refresh_token":"xxxxx.yyyyy.zzzzz",
    "scope":"SCOPE" 
}

Комбинация имеет следующие преимущества:

  • Токены Oauth2.0 также могут быть без гражданства (хотя также используются черные списки)
  • Токен Oauth2.0 также может нести некоторые общие данные.
  • Как упоминалось ранее, обновление JWT, когда необходимо ограничить продление обновления, может привести к расширению библиотеки черного списка, но в сочетании с Oauth2.0, черезrefresh_tokenМеханизм позволяет изменить срок действия токенов в библиотеке черного списка с «времени обновления» обратно на «время истечения срока действия», тем самым решая эту проблему.

7. Десять вещей, которые вы должны знать о токенах

Это мой пост от организации Auth010 Things You Should Know about TokensСогласованный:

  1. После того, как Токен получен, его нужно сохранить для следующего использования, его можно хранить в localstorage/sessionstorage/cookie.

  2. Токен содержит срок действия, вы должны развернуть некоторую логику для управления сроком действия

  3. Междоменные ограничения localstorage/sessionstorage строже, чем у файлов cookie, и рекомендуется использовать файлы cookie.

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

    Почему существует запрос OPTIONS?

  5. Запрос на загрузку файла можно легко обработать с помощью файла cookie, но токены обычно запрашиваются через XHR, поэтому вам нужно развернуть дополнительную логику. Например, создайте билет в реальном времени, получите к нему доступ с помощью билета, затем проверьте, перенаправьте и, наконец, загрузите файл.

  6. Разобраться с XSS проще, чем с CSRF (правда не вижу в чем логика, можете прочитать исходный текст)

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

  8. Зашифруйте токен, если в нем закодирована конфиденциальная информация.

  9. Веб-токен JSON можно использовать в токене носителя Oauth2.0, что дает Oauth2.0 преимущество отсутствия состояния.

  10. Токен не панацея, пожалуйста, выбирайте в соответствии с реальными потребностями бизнеса

перепечатыватьСверхдетальный анализ JWT

Категории