Непрозрачный токен против JWT

В Logto, как в комплексной CIAM-платформе на основе OIDC, токены авторизации играют важную роль в обеспечении безопасности взаимодействия пользователей и управлении доступом к ресурсам. Среди различных типов токенов, используемых для авторизации, непрозрачные токены и JWT (JSON веб-токены) являются наиболее важными.

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

Что такое непрозрачный токен?#

Непрозрачный токен — это тип токена доступа, который, как следует из названия, является непрозрачным или нетранспарентным для клиента или любой внешней стороны. Это означает, что сам токен не несет никакой читаемой информации о пользователе или предоставленной авторизации.

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

Вот пример непрозрачного токена:

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

Плюсы:

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

Минусы:

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

Что такое JWT?#

В отличие от непрозрачных токенов, JWT (JSON веб-токен) - это автономный, не требующий состояния токен, который несет информацию в структурированном и читаемом формате.

JWT состоит из трех частей: заголовка, полезной нагрузки и подписи, каждая из которых закодирована в Base64URL.

Вот пример JWT:

• заголовок содержит информацию о типе токена и используемом алгоритме для подписи. Например, {"alg": "HS256", "typ": "JWT"}.
• полезная нагрузка содержит утверждения — части информации о пользователе или авторизации, такие как идентификатор пользователя, время истечения срока и области действия. Поскольку эти данные закодированы, но не зашифрованы, каждый имеющий токен может его декодировать для просмотра утверждений, хотя не может изменить его, не нарушив целостность подписи. В зависимости от спецификации и конфигурации сервера авторизации, в полезной нагрузке могут быть включены различные утверждения. Это придает токену его автономный характер. Например, {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
• подпись генерируется путем объединения заголовка, полезной нагрузки и секретного ключа с использованием указанного алгоритма. Эта подпись используется для проверки целостности токена и гарантии, что он не был изменен.

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

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

Плюсы:

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

Минусы:

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

Проверка непрозрачных токенов доступа#

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

1. Клиент запрашивает токен доступа у сервера авторизации.
2. Сервер авторизации выдает непрозрачный токен.
3. Клиент отправляет запрос на доступ к ресурсу с непрозрачным токеном в заголовке.
4. Поставщик ресурсов отправляет запрос на introspection токена серверу авторизации для его проверки.
5. Сервер авторизации отвечает информацией о токене.

Проверка токена доступа JWT (офлайн)#

Токен доступа JWT может быть проверен в автономном режиме клиентом или любой службой, имеющей доступ к открытому ключу токена.

0. Поставщик ресурсов предварительно получает открытый ключ сервера авторизации с точки обнаружения OIDC. Открытый ключ используется для проверки подписи токена и обеспечения его целостности.
1. Клиент запрашивает токен доступа у сервера авторизации.
2. Сервер авторизации выдает токен JWT.
3. Клиент отправляет запрос на доступ к ресурсу с токеном JWT в заголовке.
4. Поставщик ресурсов декодирует и проверяет JWT токен, используя открытый ключ, полученный от сервера авторизации.
5. Поставщик ресурсов предоставляет доступ на основе действительности токена.

Примеры использования в OIDC#

В контексте OIDC (OpenID Connect) непрозрачные токены и JWT служат разным целям и используются в разных сценариях.

Непрозрачные токены#

1. Получение профиля пользователя:

По умолчанию, когда клиент запрашивает токен доступа, не указывая ресурс и включая область действия openid, сервер авторизации выдает непрозрачный токен доступа. Этот токен используется в основном для получения информации о профиле пользователя с конечной точки OIDC /oidc/userinfo. После получения запроса с непрозрачным токеном доступа сервер авторизации проверяет свою внутреннюю базу данных для извлечения связанной информации об авторизации и проверяет действительность токена, прежде чем ответить с подробностями профиля пользователя.

2. Обмен токенами обновления:

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

JWT#

1. ID токен:

В OIDC ID токен — это JWT, содержащий информацию о пользователе и используемый для аутентификации пользователя. Обычно выдается вместе с токеном доступа, ID токен позволяет клиенту проверить личность пользователя. Например:

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

2. Доступ к ресурсам API:

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

Поставщик ресурсов может проверить запрос, проверив утверждения:

• iss: Подтверждает, что токен выдан доверенным сервером авторизации.
• sub: Идентифицирует пользователя, связанного с токеном.
• aud: Обеспечивает, что токен предназначен для конкретного ресурса.
• scope: Проверяет разрешения, предоставленные пользователю.

Заключение#

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

Откройте для себя больше функций токенов доступа в Logto:

• Используйте RBAC для защиты вашего API
• Токен доступа для организаций
• Пользовательские утверждения JWT