Инструменты разработчика · Декодер JWT
Семь зарегистрированных JWT претензий: iss, sub, aud, exp, nbf, iat и jti.
· Фон
JWT форматы данных аутентификация
RFC 7519 резервирует семь имен утверждений с определенными значениями и типами. В этом посте объясняется каждый из них, стоящие за ними типы StringOrURI и NumericDate, а также то, как сосуществуют зарегистрированные, общедоступные и частные утверждения.
Какие имена утверждений следует использовать? — вопрос о дизайне, на который отвечает реестр.
Выбор имен утверждений частично зависит от совместимости. Повторное использование зарегистрированного имени дает читателям и библиотекам установленное значение, тогда как имена, специфичные для приложения, требуют местной документации. ToolAcre распознает семь основных имен в своей таблице описания и оставляет видимыми другие утверждения без назначения семантики.
Знакомое имя не является автоматически заслуживающим доверия. Декодер считывает любой объект, содержащийся в токене, и никогда не проверяет его подпись. Зарегистрированный словарь помогает людям классифицировать данные; только доверенный проверяющий может установить, что эмитент предоставил защищенное значение.
iss и sub отображаются как строки; эта реализация не обеспечивает соблюдение синтаксиса StringOrURI
`iss` определяет, кто выдал его по утверждениям токена, а `sub` определяет, о ком или о чем идет речь. ToolAcre описывает оба и отображает их значения, но его реализация не проверяет грамматику StringOrURI и не сравнивает ни одно поле с конфигурацией службы.
Верификатор должен привязать ожидаемого эмитента к доверенному ключевому материалу и интерпретировать субъект в пространстве имен этого эмитента. Копирование строки известного эмитента в сфабрикованные полезные данные придает декодеру убедительный вид без установления происхождения. Используйте эти поля только после криптографической проверки.
aud — предполагаемые получатели в виде строки или массива
`aud` описывает предполагаемых получателей и может быть представлено как одно значение или список в соответствии с применимыми правилами токена. Общая таблица утверждений ToolAcre сохраняет массивы как текст JSON, но не решает, отображается ли в них текущая служба.
Аудитория контекстуальна. Один и тот же аутентифицированный токен может подходить для одного API и не подходить для другого. Серверу ресурсов нужен ожидаемый идентификатор в доверенной конфигурации, и он должен отклонять несоответствие, а не позволять токену определять, где его следует принять.
exp, nbf и iat — три утверждения NumericDate, которые связывают токен во времени.
`exp`, `nbf` и `iat` являются утверждениями NumericDate. ToolAcre обрабатывает конечные числа как секунды, прошедшие с эпохи, умножается на 1,000 для отображения даты и помечает срок действия или не раньше относительно часов браузера. Он не определяет свободу действий и не обеспечивает принятие решения сервером.
Срок действия отмечает заявленную конечную границу, а не является доказательством того, что токен когда-либо был действительным. Not-before отмечает заявленную начальную границу, а Issue-at записывает заявленное время создания. Каждый из них может быть подделан в полезной нагрузке, поэтому арифметика времени должна следовать за проверкой подписи в доверенном потоке.
jti — уникальный идентификатор для обнаружения повторов и списков запретов.
`jti` — идентификатор токена. Системы могут использовать аутентифицированный, соответствующим образом сгенерированный идентификатор для отслеживания воспроизведения или состояния отзыва, но само по себе утверждение не предоставляет ни одного свойства. ToolAcre описывает его как идентификатор токена для обнаружения повтора и отображает его точное значение.
Уникальность, поведение хранения и поиска относятся к архитектуре эмитента и верификатора. Декодер не может определить, использовал ли идентификатор повторно другой токен или он содержится в списке запретов. Считайте его потенциальным значением корреляции до тех пор, пока окружающая доверенная система не предоставит доказательства.
Зарегистрированные описания и заявления для конкретных приложений на дисплее ToolAcre.
Реализация различает зарегистрированные имена только посредством пояснительного текста. Каждое свойство полезной нагрузки по-прежнему возвращается `listClaims`; неизвестным именам присваивается нулевое описание, и пользовательский интерфейс помечает их как зависящие от приложения. Он не обращается к общедоступному реестру и не предотвращает конфликты частных имен.
Эта граница позволяет избежать претензий на большее, чем доказывает источник. Команды должны документировать свои частные претензии и выбирать имена, устойчивые к коллизиям, когда совместимость имеет значение. Отсутствие описания в декодере означает «нет в этой локальной таблице из семи имен», не «недействительно» или «безопасно игнорировать».
Рабочий пример — считывание реалистичной полезной нагрузки и классификация каждой претензии.
Рассмотрим `{"iss":"https://issuer.example","sub":"user-7","aud":["orders"],"exp":1717246800,"nbf":1717243100,"iat":1717243200,"jti":"demo-9","tenant":"north"}`. ToolAcre описывает семь зарегистрированных полей и меток `tenant` для конкретного приложения при форматировании трех числовых значений.
Эта классификация помогает анализировать конструкцию полезной нагрузки. Он не аутентифицирует URL, тему, аудиторию, даты, идентификатор или арендатора. Поддельный жетон может точно воспроизвести объект. Вставляйте в логику авторизации только проверенные утверждения, а затем применяйте ожидаемые значения службы-потребителя.
Вывод: используйте зарегистрированные имена, когда они подходят — декодер ToolAcre JWT показывает полезную нагрузку, чтобы вы могли видеть, какие утверждения устанавливает реальный эмитент.
Используйте зарегистрированные имена, когда их определенное значение соответствует, поскольку узнаваемый словарный запас сокращает количество ненужных переводов. Держите частные поля документированными и минимальными. Не перегружайте `sub`, `aud` или требование времени с другим локальным значением только потому, что нижестоящий код уже анализирует этот ключ.
ToolAcre может показать, какие имена несет безопасный токен и как отображаются его числовые утверждения. Он не может подтвердить какую-либо ценность. Полезным результатом декодирования является инвентаризация для анализа; Полезным результатом проверки и политики является решение, и они остаются отдельными.