ID Token и Access Token: ключевое различие в OpenID Connect

By Mirko Peters · 2026-10-28

Разбираем важные различия между ID-токенами и токенами доступа в OpenID Connect и выясняем, почему их путаница создает серьезные уязвимости безопасности.

Automatically translated with AI from the original post. Read the English original

Понимание различия между ID-токеном и токеном доступа важно для разработчиков и ИT-администраторов, работающих с современной аутентификацией. OAuth 2.0 отвечает за разрешения, а OpenID Connect добавляет ID-токен, который подтверждает личность пользователя. Путаница между этими двумя разными токенами приводит к критическим уязвимостям безопасности в облачных приложениях.

Главное

• ID-токены подтверждают личность пользователя, а токены доступа предоставляют авторизацию и разрешения.
• Путаница между этими двумя токенами — одна из основных ошибок в безопасности самописных приложений.
• OpenID Connect добавляет подтверждение личности поверх фреймворка OAuth 2.0.
• Токены доступа можно отозвать, что делает модель безопасности надежнее, чем хранение паролей.
• Приложения должны криптографически проверять входящие ID-токены, а не доверять им вслепую.

Главная дилемма: идентификация против авторизации

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

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

OpenID Connect закрыл именно этот пробел, введя стандартизированный уровень, предназначенный для аутентификации. Используя второй токен наряду с традиционным токеном доступа, OpenID Connect четко отделяет вопрос идентичности от вопроса разрешений. Разделение этих двух понятий — самый важный сдвиг в мышлении для тех, кто сегодня создает или аудитирует облачные приложения.

Анатомия ID-токена: что находится внутри

Когда пользователь нажимает кнопку «Войти с Microsoft», поставщик удостоверений обрабатывает учетные данные, выполняет требования многофакторной аутентификации и в итоге возвращает пользователя в приложение вместе с ID-токеном. Этот токен упакован в формате JSON Web Token, сокращенно JWT, который произносится как «джот». На первый взгляд JWT выглядит как пугающая, непроницаемая строка символов, разделенных точками. Однако после декодирования его внутренняя структура удивительно проста.

Внутри ID-токена находится несколько стандартных утверждений (claims), и каждое из них выполняет строго определенную функцию:

• Issuer: Идентифицирует конкретного поставщика удостоверений (например, Microsoft Entra ID), который создал и подписал токен.
• Subject (sub): Служит уникальным неизменяемым идентификатором пользователя. Важно, что он не меняется, даже если пользователь обновляет отображаемое имя или адрес электронной почты.
• Audience (aud): Указывает, для какого именно приложения был создан токен, что гарантирует: токен, предназначенный одному приложению, не может быть перехвачен и повторно использован другим.
• Timestamps: Содержат время выдачи токена, время его истечения и точный момент, когда пользователь прошёл аутентификацию.
• Nonce: Работает как защищённый номер квитанции, связывающий итоговый токен с конкретным сеансом входа, который инициировал запрос, и тем самым эффективно блокирует атаки повторного воспроизведения.

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

Опасность отождествления идентификации с доступом

Один из самых опасных антипаттернов в разработке приложений — считать ID-токен ключом доступа. Поскольку ID-токен подтверждает, что пользователь — это Джон Доу из конкретной организации, начинающие разработчики иногда используют это подтверждение, чтобы выдать административные права или неограниченный доступ к базе данных. Это фундаментально неверно понимает архитектуру.

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

Кроме того, приложения нередко допускают ошибку, принимая входящие ID-токены без надлежащих проверок. Слепое доверие к токену только потому, что библиотека обработала его «за кулисами», оставляет системы уязвимыми для подделанных данных. Проверка подписи, контроль времени истечения и проверка утверждения audience — обязательные шаги для поддержания безопасности.

Заключение

Понимание границы между идентификацией и авторизацией помогает разобраться в устройстве современной облачной архитектуры. Если держать ID-токены строго для подтверждения того, кто находится за клавиатурой, а токены доступа оставить для определения допустимых действий, разработчики смогут создавать надёжные и безопасные интеграции с платформами вроде Microsoft Entra ID. Чтобы услышать подробный разбор этих концепций и понять, как работают современные сценарии входа в экосистеме Microsoft, посмотрите полное обсуждение. Слушайте полный эпизод и углубитесь в механику облачной идентификации уже сегодня!

Часто задаваемые вопросы

Можно ли использовать ID-токен для вызова API или доступа к защищённым ресурсам?

Нет. ID-токен содержит только утверждения об идентичности пользователя. Для вызова API или доступа к защищённым ресурсам приложение должно использовать токен доступа, выданный через OAuth 2.0.

Зачем OpenID Connect и OAuth 2.0 используют отдельные токены?

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

Что произойдёт, если приложение примет ID-токен без проверки подписи?

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

Какое место занимает значение «nonce» в обмене токенами?

Nonce — это случайная строка, которая генерируется в начале потока входа и встраивается в ID-токен, что позволяет приложению предотвращать атаки повторного воспроизведения.