ID Token проти Access Token: ключова різниця в OpenID Connect

By Mirko Peters · 2026-10-28

Розберіться в ключових відмінностях між ID-токенами та access-токенами в OpenID Connect і дізнайтеся, чому їх плутанина створює серйозні вразливості безпеки.

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

Розуміння різниці між ID-токеном і access-токеном є критично важливим для розробників і ІТ-адміністраторів, які працюють із сучасною автентифікацією. OAuth 2.0 відповідає за дозволи, а OpenID Connect додає ID-токен, щоб підтверджувати ідентичність користувача. Плутанина між цими двома різними токенами призводить до критичних вразливостей безпеки у хмарних застосунках.

Головне

• ID-токени підтверджують ідентичність користувача, тоді як access-токени надають авторизацію та дозволи.
• Плутанина між цими двома токенами є основною помилкою в безпеці самостійно розроблених застосунків.
• OpenID Connect надбудовує підтвердження ідентичності над фреймворком OAuth 2.0.
• Access-токени можна відкликати, що забезпечує безпечніший захист, ніж зберігання паролів.
• Застосунки мусять криптографічно перевіряти вхідні ID-токени, а не довіряти їм без перевірки.

Основна дилема: ідентичність проти авторизації

У розвитку сучасних вебзастосунків розробники часто стикаються з плутаниною щодо того, як користувачі входять у систему і як ті самі користувачі взаємодіють з основними даними. Велика частина цієї плутанини походить від термінології, що перетинається в сфері ідентичності. Коли застосунки почали стрімко поширюватися вебом, покладатися виключно на базові комбінації логіна та пароля стало серйозним безпековим обмеженням. Користувачі втомлювалися від керування десятками унікальних облікових даних, через що паролі масово повторювалися на різних платформах.

Для часткового вирішення цієї проблеми з'явився OAuth 2.0. Утім, OAuth 2.0 ніколи не створювався для того, щоб відповідати на питання, хто є людина. Його головне призначення — видавати дозволи, відомі як access-токени, які дають застосунку змогу звертатися до конкретних кінцевих точок даних від імені користувача. Access-токен визначає, що застосунок може робити, але повністю мовчить про ідентичність того, хто його використовує. Ця фундаментальна прогалина означала, що компаніям, які намагалися створити досвід єдиного входу (single sign-on), доводилося самостійно добудовувати власні перевірки ідентичності поверх OAuth. Так виникали фрагментовані реалізації, які рідко узгоджувалися між собою.

OpenID Connect заповнив саме цю прогалину, запровадивши стандартизований шар, призначений спеціально для автентифікації. Використовуючи другий токен поряд із традиційним access-токеном, OpenID Connect чітко відокремлює питання ідентичності від питань дозволів. Розділення цих двох понять — найважливіша зміна мислення для кожного, хто сьогодні створює або аудитує хмарні застосунки.

Анатомія ID-токена: що всередині

Коли користувач натискає кнопку «Увійти через Microsoft», постачальник ідентичності обробляє облікові дані, виконує вимоги багатофакторної автентифікації і, зрештою, повертає користувача до застосунку разом з ID-токеном. Цей токен оформлено як JSON Web Token, скорочено JWT, який вимовляється як «джот». На перший погляд JWT виглядає як складний і непроникний рядок символів, розділених крапками. Проте після декодування його внутрішня структура напрочуд проста.

Всередині ID-токена є кілька стандартних тверджень, кожне з яких має чітко визначене призначення:

• Issuer (емітент): визначає конкретного постачальника ідентичності (наприклад, Microsoft Entra ID), який створив і підписав токен.
• Subject (sub): Слугує унікальним незмінним ідентифікатором користувача. Важливо, що він не змінюється навіть тоді, коли користувач оновлює відображуване ім’я чи адресу електронної пошти.
• Audience (aud): Вказує, для якого саме застосунку створено токен. Це гарантує, що токен, призначений для одного застосунку, не можна перехопити й зловмисно повторно використати в іншому.
• Часові мітки: Показують, коли токен було видано, коли він спливає і точний момент, коли користувач пройшов автентифікацію.
• Nonce: Працює як безпечний номер квитанції, який прив’язує отриманий токен до конкретного сеансу входу, що його ініціював. Так фактично блокуються атаки повторного відтворення (replay attacks).

Найважливіше те, що весь пакет підписується приватним ключем постачальника. Застосунок-отримувач перевіряє цей підпис за відповідним відкритим ключем, який опублікував постачальник. Без такої криптографічної перевірки ID-токен — це лише неперевірена записка, передана між сторонами.

Небезпека сприйняття ідентифікації як доступу

Один із найнебезпечніших антипатернів у розробці застосунків — сприймати ID-токен як ключ до дозволів. Оскільки ID-токен підтверджує, що користувач — це Джон Доу з певної організації, недосвідчені розробники іноді помилково використовують це підтвердження, щоб надати адміністративні права або необмежений доступ до бази даних. Це принципово хибне розуміння архітектури.

ID-токен лише повідомляє, хто стоїть на порозі; він нічого не каже про те, чи може ця людина відкривати всі внутрішні кімнати або натискати конкретну адміністративну кнопку. Логіку авторизації застосунок має реалізовувати окремо, наприклад через role-based access control або подібні механізми, використовуючи перевірену ідентичність як відправну точку, а не як остаточне рішення про авторизацію.

Крім того, застосунки часто припускаються помилки, приймаючи вхідні ID-токени без належної перевірки. Сліпа довіра до токена лише тому, що бібліотека обробила його за лаштунками, залишає системи вразливими до підроблених даних. Перевірка підпису, контроль часових міток закінчення строку дії та перевірка твердження про аудиторію (audience) — обов’язкові кроки для підтримання безпечного стану.

Висновок

Розуміння межі між ідентифікацією та авторизацією допомагає розібратися в сучасній хмарній архітектурі. Якщо ID-токени суворо відповідають лише за підтвердження того, хто сидить за клавіатурою, а токени доступу визначають, які дії дозволено, розробники можуть створювати надійні та безпечні інтеграції з такими платформами, як Microsoft Entra ID. Щоб послухати детальний огляд цих концепцій і дізнатися, як працюють сучасні процеси входу в екосистемі Microsoft, перегляньте повну дискусію. Послухайте повний епізод і сьогодні ж поглибтеся в механіку хмарної ідентифікації!

Поширені запитання

Чи можна використовувати ID-токен для виклику API або доступу до захищених ресурсів?

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

Навіщо OpenID Connect і OAuth 2.0 використовують окремі токени?

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

Що станеться, якщо застосунок прийматиме ID-токен без перевірки підпису?

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

Де в обміні токенами використовується значення «nonce»?

Nonce — це випадковий рядок, який генерується на початку процесу входу та вбудовується в ID-токен. Це дозволяє застосунку запобігати атакам повторного відтворення.