RFC 9068 визначає сумісний профіль JWT access token для OAuth 2.0. Він фіксує typ=at+jwt, обов’язкові claims, правила підпису та перевірки, щоб resource server не сприйняв ID token або довільний JWT як дозвіл на доступ.
Явний typ зменшує плутанину токенів
Header має позначати access token через at+jwt. Перевірник не повинен приймати токен лише тому, що підпис правильний: ключ authorization server може підписувати й інші типи JWT. Type, issuer, audience та призначення перевіряють разом.
Підпис обов’язковий
Алгоритм none заборонений, а asymmetric cryptography рекомендована для розповсюдження validation keys. Сервер не довіряє alg із header без власної allowlist. JWK отримують із довіреної metadata, кешують із контрольованим оновленням і обробляють ротацію kid.
Claims мають конкретну семантику
iss визначає видавця, aud — цільовий ресурс, exp — завершення, iat — час випуску, jti — ідентифікатор, client_id — клієнта, sub — principal. Scope або authorization details описують права. Відсутній чи неправильний audience є причиною відмови.
Локальна перевірка має компроміси
JWT дозволяє перевірити токен без запиту introspection, але відкликання не стає миттєвим. Короткий строк зменшує вікно, а критичні сценарії можуть потребувати denylist або online check. Токен не слід наповнювати зайвими персональними даними, бо bearer бачить payload.
Помилки не повинні витікати клієнту
Resource server може журналювати точну внутрішню причину, але зовнішня відповідь не розкриває ключі, допустимі audiences або policy details. Метрики розділяють expired, signature, issuer, audience і authorization failures, щоб відрізнити атаку від розсинхронізації конфігурації.
Експлуатаційний контроль
Після впровадження команда відстежує причини token rejection, вік ключів, audience mismatches, expired tokens і authorization denials. Показники пов’язують із версією конфігурації, середовищем і конкретним сценарієм: середнє значення без цього контексту може приховати рідкісну критичну помилку. Для кожного порогу визначають власника, канал сповіщення, строк реакції та безпечну дію. Набір тестів і рішення переглядають, коли змінюється issuer, JWK, audience, claim mapping, token lifetime або resource policy. Історію змін зберігають, щоб відрізнити реальне покращення від зміни методики вимірювання.
Практичний чекліст
- вимагати typ at+jwt
- зафіксувати allowlist алгоритмів
- перевіряти iss, aud, exp та права
- планувати JWK rotation і cache
- не вміщувати зайві персональні дані
Висновок
Корисне впровадження починається з чіткого сценарію, перевірних припущень і малого пілота. Команда документує не лише успішну конфігурацію, а й межі, невизначеність, спосіб відмови та умови повторної оцінки. Так специфікація або інструмент стає частиною керованого процесу, а не формальною позначкою.
Першоджерела: RFC 9068.
Коментарі
Щоб залишити коментар, увійдіть через Google.