Непрозрачный токен против JWT
Поймите различия между непрозрачными токенами и JWT, их применением и способом проверки в системах на основе OIDC.
Поймите различия между непрозрачными токенами и JWT, их применением и способом проверки в системах на основе OIDC.
В Logto, как в комплексной CIAM-платформе на основе OIDC, токены авторизации играют важную роль в обеспечении безопасности взаимодействия пользователей и управлении доступом к ресурсам. Среди различных типов токенов, используемых для авторизации, непрозрачные токены и JWT (JSON веб-токены) являются наиболее важными.
Мы получили несколько вопросов от нашего сообщества, например: в чем разница между непрозрачным токеном и JWT? Почему я не могу декодировать полученный токен доступа и почему длина токена кажется короткой? Этот блог-пост направлен на разъяснение этих концепций и поможет вам понять различия между непрозрачными токенами и JWT, их вариантами использования и почему вы можете столкнуться с разным поведением при работе с ними.
Непрозрачный токен — это тип токена доступа, который, как следует из названия, является непрозрачным или нетранспарентным для клиента или любой внешней стороны. Это означает, что сам токен не несет никакой читаемой информации о пользователе или предоставленной авторизации.
Когда вы получаете непрозрачный токен, он часто представляется как кажущаяся случайная строка символов, и попытка его декодирования не принесет никакой значимой информации.
Вот пример непрозрачного токена:
Поскольку фактическое содержание токена известно только серверу авторизации, который его выдал, для проверки непрозрачного токена клиент должен отправить его обратно на сервер, который затем проверяет его подлинность и определяет связанные с ним разрешения. Этот подход гарантирует, что конфиденциальная информация остается скрытой, обеспечивая дополнительный уровень безопасности, но также требует дополнительной связи с сервером для проверки токена.
Плюсы:
Минусы:
В отличие от непрозрачных токенов, JWT (JSON веб-токен) - это автономный, не требующий состояния токен, который несет информацию в структурированном и читаемом формате.
JWT состоит из трех частей: заголовка, полезной нагрузки и подписи, каждая из которых закодирована в Base64URL.
Вот пример JWT:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cзаголовок содержит информацию о типе токена и используемом алгоритме для подписи. Например, {"alg": "HS256", "typ": "JWT"}.полезная нагрузка содержит утверждения — части информации о пользователе или авторизации, такие как идентификатор пользователя, время истечения срока и области действия. Поскольку эти данные закодированы, но не зашифрованы, каждый имеющий токен может его декодировать для просмотра утверждений, хотя не может изменить его, не нарушив целостность подписи. В зависимости от спецификации и конфигурации сервера авторизации, в полезной нагрузке могут быть включены различные утверждения. Это придает токену его автономный характер. Например, {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.подпись генерируется путем объединения заголовка, полезной нагрузки и секретного ключа с использованием указанного алгоритма. Эта подпись используется для проверки целостности токена и гарантии, что он не был изменен.JWT широко используется, так как его можно проверить локально клиентом или любой услугой без необходимости обращения к серверу авторизации. Это делает JWT особенно эффективными для распределенных систем, где множество служб могут потребовать проверить подлинность токена независимо.
Однако это удобство также влечет за собой ответственность за обеспечение того, чтобы утверждения токена не были чрезмерно раскрыты, так как они видны каждому, у кого есть доступ к токену. Кроме того, JWT обычно имеют короткий срок действия, а время истечения срока включено в утверждения токена, чтобы гарантировать, что токен не будет действителен бесконечно.
Плюсы:
Минусы:
Непрозрачный токен доступа проверяется путем его отправки обратно на сервер авторизации для проверки. Сервер авторизации поддерживает состояние выданных токенов и может определить их действительность на основе своей внутренней базы данных.
Токен доступа JWT может быть проверен в автономном режиме клиентом или любой службой, имеющей доступ к открытому ключу токена.
В контексте OIDC (OpenID Connect) непрозрачные токены и JWT служат разным целям и используются в разных сценариях.
По умолчанию, когда клиент запрашивает токен доступа, не указывая ресурс и включая область действия openid, сервер авторизации выдает непрозрачный токен доступа. Этот токен используется в основном для получения информации о профиле пользователя с конечной точки OIDC /oidc/userinfo. После получения запроса с непрозрачным токеном доступа сервер авторизации проверяет свою внутреннюю базу данных для извлечения связанной информации об авторизации и проверяет действительность токена, прежде чем ответить с подробностями профиля пользователя.
Токены обновления предназначены для обмена только между клиентом и сервером авторизации без необходимости делиться ими с поставщиками ресурсов. Таким образом, токены обновления обычно выдаются в виде непрозрачных токенов. Когда текущий токен доступа истекает, клиент может использовать непрозрачный токен обновления для получения нового токена доступа, обеспечивая непрерывный доступ без повторной аутентификации пользователя.
В OIDC ID токен — это JWT, содержащий информацию о пользователе и используемый для аутентификации пользователя. Обычно выдается вместе с токеном доступа, ID токен позволяет клиенту проверить личность пользователя. Например:
Клиент может проверить ID токен, чтобы подтвердить личность пользователя и извлечь информацию о пользователе для персонализации или целей авторизации. ID токен предназначен для одноразового использования и не должен использоваться для авторизации ресурсов API.
Когда клиент запрашивает токен доступа с указателем на конкретный ресурс, сервер авторизации выдает токен JWT, предназначенный для доступа к этому ресурсу. JWT содержит утверждения, которые поставщик ресурсов может использовать для авторизации доступа клиента. Например:
Поставщик ресурсов может проверить запрос, проверив утверждения:
iss: Подтверждает, что токен выдан доверенным сервером авторизации.sub: Идентифицирует пользователя, связанного с токеном.aud: Обеспечивает, что токен предназначен для конкретного ресурса.scope: Проверяет разрешения, предоставленные пользователю.В итоге, непрозрачные токены и JWT служат разным целям в системах на основе OIDC, при этом непрозрачные токены обеспечивают безопасный и основанный на состояниях подход к авторизации, а JWT предлагает автономную и не требующую состояния альтернативу. Понимание различий между этими типами токенов и их вариантами использования важно для разработки безопасных и эффективных механизмов аутентификации и авторизации в ваших приложениях.
Откройте для себя больше функций токенов доступа в Logto: