Refresh Token проти Access Token: у чому різниця і чому це важливо в Microsoft Entra ID

By Mirko Peters · 2026-04-28

Refresh Token проти Access Token: у чому різниця і чому це важливо в Microsoft Entra ID

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

Якщо ви колись замислювалися, що насправді відрізняє refresh token від access token, ви потрапили за адресою. У непростому світі Microsoft Entra ID і сучасної хмарної безпеки ці два типи токенів відіграють ключові ролі, і кожен має своє призначення, свої особливості та свої правила безпеки. Добре розуміння цих відмінностей може врятувати вас під час проєктування безпечних сценаріїв входу для Microsoft 365, Azure або будь-якого застосунку, пов’язаного з платформою Entra.

Це не просто теорія. Знати, який токен використовувати і коли, де його зберігати і як надійно захищати, — базова навичка для будь-якого ІТ-спеціаліста, розробника чи адміністратора в екосистемі Microsoft. Вибір впливає не лише на безпеку вашого застосунку, а й на щоденний досвід користувачів, особливо коли йдеться про те, щоб залишатися в системі або відновлюватися після інцидентів безпеки.

У цьому посібнику ви побачите, як access token і refresh token вписуються в налаштування автентифікації та авторизації, чому важливий їхній термін дії і що робить кожен з них унікальним, особливо в середовищах Microsoft Entra ID. Наприкінці ви зрозумієте, як поєднати надійні заходи безпеки з зручністю для користувачів, розбираючись у тонкощах управління токенами в хмарі.

Розуміння токенів у сучасній автентифікації

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

Токени є основою фреймворку OAuth 2.0, який забезпечує входи і безпечний доступ на таких платформах, як Microsoft Entra ID. Замість керування ідентифікаторами сесій або крихкими cookie застосунки тепер покладаються на ці розумні цифрові «перепустки», щоб ідентифікувати користувачів і надавати доступ до чутливих хмарних ресурсів. Такий підхід зробив безпеку одночасно суворішою і зручнішою для великих організацій, які переходять у хмару.

Усе працює завдяки тому, що для різних завдань існують різні типи токенів. Одні призначені для тимчасового доступу: швидкі й одноразові. Інші підтримують сесії у фоновому режимі, дозволяючи працювати весь день без постійних повторних входів. Саме це розмежування між access token і refresh token має вирішальне значення для того, як хмарні сервіси Microsoft, зокрема Entra ID, балансують між зручністю для користувачів і безпекою організації.

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

Що таке токен?

Токен у цифровій безпеці — це компактний фрагмент даних, який виступає цифровим обліковим посвідченням. Уявіть його як цифрову версію ключової картки: застосунок пред’являє її, щоб довести вашу особу або права іншій системі. Токени можна використовувати для автентифікації (чи ви той, за кого себе видаєте?) і авторизації (чи маєте ви право робити те, що робите?) у хмарних застосунках і API.

Токени зазвичай базуються на сучасних стандартах, таких як OAuth 2.0, і часто мають вигляд bearer-токенів, наприклад JSON Web Tokens (JWT). Їх віддають перевагу класичним ідентифікаторам сесій, оскільки вони більш переносні, можуть містити структуровані твердження (claims) і забезпечують безпечний доступ до хмарних ресурсів та розподілених систем.

Що таке access token?

Access token — це короткоживучі цифрові облікові посвідчення, які видаються застосунку після успішної автентифікації. Їхнє основне призначення — надати тимчасовий доступ з чітко обмеженими правами до конкретних ресурсів, таких як API, дані користувачів або хмарне сховище, не розкриваючи паролі чи інші чутливі дані.

Ці токени дійсні лише обмежений час, зазвичай 30–90 хвилин у Microsoft Entra ID. Саме їх застосунки надсилають із кожним запитом до API, щоб підтвердити, що користувач має доступ. Відповідно до стандартів OAuth 2.0, access token працюють у Microsoft 365, Azure та будь-якому сервісі, підключеному до Entra ID, забезпечуючи детальні дозволи з обмеженим часом дії.

Що таке refresh token?

Refresh token — це довгоживучі облікові посвідчення, які отримують довірені застосунки після первинного входу. На відміну від access token, основне завдання refresh token — непомітно отримувати нові access token, коли поточний втрачає чинність, не змушуючи користувача автентифікуватися знову.

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

Ключові відмінності між access token і refresh token

На перший погляд access token і refresh token можуть здаватися просто випадковими рядками, але їхні ролі й терміни дії суттєво відрізняються. Вони не взаємозамінні: кожен створений для конкретного призначення в процесі автентифікації Microsoft Entra ID.

Access token — це ваш «перепустка» для викликів API та отримання даних, але лише на короткий час. Їх навмисно роблять короткоживучими, щоб мінімізувати ризики безпеки, особливо якщо токен витече. Refresh token, натомість, живе довше. Його завдання — підтримувати зручність для користувача, непомітно повторно авторизуючи доступ у фоновому режимі.

Розуміти ці відмінності — це не просто академічна вправа. Якщо обрати неправильну стратегію або зберігати токен не в тому місці, ви або змусите користувачів надто часто входити знову, або залишите серйозні діри в безпеці. Наступний блок розділів розбирає, що робить кожен токен, скільки він діє і що робить його безпечним (або ризикованим) на практиці, а не лише в теорії.

Якщо ви проєктуєте архітектуру для Microsoft 365, Azure або будь-якого сервісу, підключеного до Entra ID, зверніть увагу на наведені нижче відмінності. Саме вони визначають баланс між міцною безпекою та безперебійними сесіями для всіх користувачів.

Функціональні ролі: що вони роблять

Access token відкриває доступ до API та хмарних ресурсів, але його можливості обмежені. Щойно access token втрачає чинність, доступ пропадає, якщо у вас немає і refresh token. Refresh token — це «пропуск за лаштунки»: він дає застосунку право непомітно запитати новий access token, не турбуючи користувача повторно.

Отже, у хмарному світі Microsoft 365 і Azure access token забезпечує дії «тут і зараз», а refresh token гарантує, що ці дії можуть продовжуватися у фоновому режимі, сесія за сесією. Такий тандем забезпечує безпечні робочі процеси й позбавляє користувачів постійних проблем з повторною автентифікацією.

Скільки живуть токени і чому важливий термін дії

Access token має короткий термін дії не просто так: за замовчуванням у Entra ID це зазвичай від 30 до 90 хвилин. Вони призначені для того, щоб надати лише достатній доступ до закінчення терміну, зменшуючи ризик у разі витоку. Refresh token, своєю чергою, — це стаєри. Вони часто діють дні, тижні або навіть місяці, залежно від потреб застосунку та налаштованих політик безпеки.

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

Характеристики безпеки access і refresh token

• 1. Безпека access token: Access token призначений для негайного, тимчасового використання. Оскільки він зазвичай діє менше години, вікно ризику за його викрадення невелике. Однак, оскільки це bearer-токени, тобто їх може використати будь-хто, хто має токен, їх слід передавати лише через HTTPS і зберігати в пам’яті, а не в постійному сховищі на клієнті.
• 2. Безпека refresh token: Refresh token живе довго і є чутливішим. Якщо refresh token скомпрометовано, зловмисник може постійно отримувати нові access token навіть після того, як користувач вийшов із системи. Тому безпечне зберігання критично важливе, бажано в захищеному середовищі (наприклад, апаратно захищеному сховищі на мобільних пристроях або у cookie з прапорцями HTTP-only і Secure у браузерах).
• 3. Поверхні атак: Access token можуть перехопити під час передавання, якщо HTTPS не забезпечено, або знайти в дампах пам’яті. Refresh token, якщо їх зберігати в local або session storage, дуже вразливі до атак міжсайтового скриптингу (XSS). Для додаткового захисту в середовищах Microsoft застосовуйте політики умовного доступу (Conditional Access) і відстежуйте незвичне використання токенів.
• 4. Відкликання та ризики: Токени доступу зазвичай не можна відкликати до закінчення строку дії, адже вони часто є безстановими JWT. Натомість токени оновлення можна активно відкликати або анулювати на боці сервера авторизації, якщо виявлено компрометацію. Про реальні ризики та заходи контролю для довготривалих токенів читайте в цьому огляді атак через згоду OAuth у Entra ID, де зловмисники використовують довготривалий доступ через токени оновлення.
• 5. Захисні заходи в хмарі Microsoft: Поєднання короткоживучих токенів доступу, суворого контролю згоди, якісного журналювання та примусового застосування адміністративної згоди разом може суттєво знизити ризики. Управління безпекою, про яке йдеться в цьому епізоді подкасту про управління безпекою Entra ID, слід упроваджувати, щоб контролювати розростання ідентичностей і застосовувати ефективніші політики безпеки.

Короткоживучі токени доступу для зниження ризиків

Рішення зберігати токени доступу короткоживучими – це не параноя, а розумне управління ризиками. Якщо короткоживучий токен доступу викрадено, вікно для атаки дуже мале. Через годину або раніше він втрачає чинність, що блокує більшість спроб бічного переміщення та повторного використання токенів.

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

Довготривалі токени оновлення для безперервної повторної автентифікації

Довготривалі токени оновлення – це передусім зручність для користувачів. Замість того щоб щогодини показувати екран входу, токен оновлення дозволяє застосункам «обміняти» прострочені токени доступу на нові, часто тихо й миттєво. Це суттєво підвищує продуктивність, особливо для застосунків Microsoft 365, які використовуються протягом усього дня, або мобільних клієнтів із нестабільним зв’язком.

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

Управління життєвим циклом токенів у Microsoft Entra ID

Отримати токени – лише половина справи, а їх керування з часом визначає, наскільки добре поєднуються ваша безпека та досвід користувачів. У Microsoft Entra ID життєвий цикл токена охоплює все: від моменту створення токена доступу або оновлення до того, як і коли його поновлюють, ротують або повністю відкликають.

Цей процес визначається найкращими практиками OAuth 2.0 і специфічними для Microsoft механізмами керування сеансами. Потрібно враховувати загрози в реальному часі (наприклад, атаки повторного відтворення), проблеми з часом (наприклад, розсинхронізацію годинників) і тонкощі глобальних розподілених систем. Щоб усе це зробити правильно, слід добре розуміти ротацію токенів, кроки перевірки та шляхи відкликання.

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

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

Найкращі практики ротації та поновлення токенів

• 1. Регулярно ротуйте токени: Завжди замінюйте токени доступу після закінчення їх строку дії; не намагайтеся продовжити їх дію. Для токенів оновлення застосовуйте ротацію під час кожного використання: щоразу, коли токен використовується для отримання нового токена доступу, замінюйте його новим токеном оновлення. Це допомагає відсікти зловмисників, які могли викрасти старіший токен.
• 2. Анулюйте раніше використані токени: Зробіть стандартом відкликання (занесення до «чорного списку») токена оновлення одразу після його заміни новим. Так лише найновіший токен оновлення залишається чинним, а потенційне вікно для атак повторного відтворення звужується.
• 3. Не передавайте токени небезпечним клієнтам: Ніколи не надсилайте refresh-токени публічним клієнтам на фронтенді, наприклад односторінковим застосункам (SPA), якщо це абсолютно необхідно. Навіть тоді використовуйте додатковий захист, наприклад Proof Key for Code Exchange (PKCE).
• 4. Стежте за підозрілим використанням: Використовуйте вбудований у Microsoft Entra ID моніторинг і сповіщення для адміністраторів про незвичне використання токенів, наприклад коли refresh-токени повторно використовуються з інших місць або пристроїв. Автоматизуйте реакцію за умовного доступу, щоб завершувати скомпрометовані сеанси та обмежувати масштаб загрози.
• 5. Відповідність вимогам для основних застосунків: Microsoft 365, Azure AD і застосунки, інтегровані з Entra ID, мають вбудовану підтримку шаблонів ротації токенів. Беріть їхні політики за замовчуванням як мінімум, наприклад одноразові refresh-токени для Exchange Online, а потім посилюйте захист там, де це потрібно для чутливих робочих навантажень.

Як видаються та перевіряються токени в Entra ID

• 1. Видача токенів (сервер авторизації): Після успішної автентифікації Microsoft Entra ID (сервер авторизації) видає токен доступу та, якщо його запитано, refresh-токен. Зазвичай це JWT, які цифрово підписуються надійними алгоритмами (наприклад, RS256) з використанням приватних ключів, якими керує Microsoft.
• 2. Твердження та вміст токенів: Токен доступу містить твердження (claims) з даними про користувача, його дозволи (області доступу) і інформацію про термін дії. Refresh-токени є непрозорими й містять те, що Entra ID потрібно для безпечного продовження сеансів.
• 3. Перевірка на серверах ресурсів: Коли ваш застосунок або API отримує токен доступу, він перевіряє цифровий підпис за допомогою опублікованого відкритого ключа підпису (з кінцевої точки JWKS у Entra ID). Перевірка гарантує, що токен справжній, не був змінений і ще дійсний (не прострочений і не відкликаний).
• 4. Перевірки безпеки: Entra ID підтримує перевірку аудиторії, дотримання областей доступу та перевірку підпису на кожному сервері ресурсів і в кожному API. Для критичних застосунків завжди перевіряйте ці твердження та підпис, перш ніж надавати доступ.
• 5. Відкликання та занесення до чорного списку: На відміну від безстанових токенів доступу, refresh-токени може відкликати Entra ID, що дозволяє швидко реагувати на підозру в компрометації. Адміністратори можуть примусово завершувати сеанси або обмежувати термін дії токенів через оновлення політик.

Пільговий період і нюанси реалізації

Пільгові періоди згладжують реальні неузгодженості в часі під час токен-автентифікації. Оскільки сервери й клієнти часто працюють з трохи різними годинниками — це проблема, яку називають розсинхронізацією годинника (clock skew), — Microsoft Entra ID при перевірці терміну дії токенів надає невеликий допуск (зазвичай близько 5 хвилин). Це не дає входу в систему завершуватися помилкою через миттєві розбіжності системного часу.

Для найкращих результатів синхронізуйте годинники всіх серверів через NTP і враховуйте, що високодоступні або багаторегіональні розгортання можуть трохи подовжувати вікна терміну дії токенів. Керуйтеся рекомендаціями щодо пільгових періодів із документації Entra ID і обов’язково тестуйте поведінку на реальному трафіку, особливо для користувачів, які переміщуються між регіонами або часовими поясами.

Безпечне зберігання та використання токенів у клієнтських застосунках

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

Якщо ви вважаєте, що зберігати токени в localStorage браузера безпечно, подумайте ще раз: достатньо однієї атаки XSS, і токен буде викрадено. Мобільні застосунки здаються безпечнішими, але root- або jailbreak-доступ може розкрити й «безпечні» токени. А в односторінкових застосунках (SPA) навіть немає безпечного сховища, недоступного для зловмисних скриптів.

Цей розділ дає потрібні рекомендації, щоб правильно обрати варіанти зберігання для різних типів застосунків. Ви побачите огляд практичних варіантів — безпечні cookie з прапорцем HTTP-only, пам’ять сеансу браузера, платформні безпечні сховища — та обов’язкові кроки для надійного захисту постійних токенів. Також ви дізнаєтеся, чому публічним клієнтам потрібна особлива увага, адже їхні клієнтські секрети не можна приховати, і як побудувати план зберігання й ротації з урахуванням ризиків для кожного сценарію.

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

Безпечне зберігання refresh-токенів для різних типів клієнтів

• 1. Веб-застосунки (браузери): Найбезпечніше місце для зберігання токенів оновлення в браузерах — це файли cookie з атрибутами HTTP-only і Secure. На відміну від localStorage чи sessionStorage, такі файли cookie не можна прочитати за допомогою JavaScript, тож вони захищені від XSS. Не зберігайте токени в localStorage — це вразливо до атак через скрипти, і там не варто тримати нічого конфіденційного.
• 2. Односторінкові застосунки (SPA): У SPA немає безпечного постійного сховища. Найкраще, що можна зробити, — тримати токени в пам’яті браузера (змінні JavaScript) протягом сеансу. Коли сторінка перезавантажується, токенів більше немає, а отже ризик зменшується. Ніколи не зберігайте токени оновлення в сховищі чи файлах cookie, які ви не контролюєте, і максимально покладайтеся на короткоживучі токени доступу та тиху поновлення.
• 3. Мобільні застосунки: Для зберігання токенів оновлення використовуйте захищену зв’язку ключів пристрою (iOS Keychain або Android Keystore). Ці сховища, захищені платформою, призначені для блокування доступу інших застосунків і системних процесів: навіть якщо телефон скомпрометовано або отримано root-доступ, витягти з нього токени непросто.
• 4. Настільні застосунки: Для зберігання постійних токенів використовуйте менеджери облікових даних на рівні операційної системи (наприклад, Windows Credential Locker). Ніколи не записуйте їх у текстові файли або в користувацькі каталоги, де їх може викрасти шкідливе ПЗ.
• 5. Корпоративні межі: У всіх випадках застосовуйте додаткові засоби контролю, такі як шифрування пристрою, блокування екрана користувача та можливість віддаленого стирання даних. Для дуже чутливих робочих навантажень вимагайте повторної автентифікації (step-up authentication) перед тим, як відкривати або використовувати токен оновлення, збережений на пристрої.

Особливі міркування щодо ротації токенів у публічних клієнтах

• 1. Публічні клієнти не можуть зберігати секрети: Публічні клієнти — SPA та деякі мобільні застосунки — не можуть безпечно приховати токени оновлення або секрети клієнта. Вважайте, що все, що зберігається, потенційно відкрите.
• 2. Використовуйте лише короткоживучі токени доступу: Мінімізуйте використання токенів оновлення або взагалі відмовтеся від них, де це можливо. Покладайтеся на короткоживучі токени доступу та запитуйте інтерактивну повторну автентифікацію замість довготривалого зберігання.
• 3. Ротуйте токени при кожному використанні: Якщо без токенів оновлення не обійтися, застосовуйте шаблони ротації одноразових токенів: видавайте новий токен оновлення при кожному наданні доступу та відкликайте попередній.
• 4. Поєднуйте з PKCE для додаткового захисту: Вимагайте Proof Key for Code Exchange (PKCE) в потоках OAuth. Це блокує більшість атак перехоплення навіть у небезпечному середовищі.

Найкращі практики керування токенами доступу та оновлення

Знати правила безпеки токенів — одне, а застосовувати їх щодня — інше. Коли йдеться про чутливі дані Microsoft 365, робочі навантаження в Azure або будь-який сценарій Entra ID, ставки вищі: потрібно поєднати надійний захист із користувацьким досвідом, щоб люди не скаржилися на надто часті входи.

Цей розділ охоплює обов’язкові дії та те, чого не варто робити, коли йдеться про керування токенами оновлення та доступу у великих масштабах. Будьмо реалістами: хмара Microsoft має свої особливості — від складної умовної автентифікації до тісної інтеграції з Microsoft Defender і Microsoft Purview для моніторингу та управління. Найкращі практики тут стосуються кожного етапу: видачі токенів, безпечного зберігання, ротації, використання і, коли треба, швидкого відкликання доступу, якщо щось пішло не так.

Далі — практичні висновки, які можна впровадити вже зараз, щоб ваші застосунки забезпечували подвійну обіцянку «швидше і безпечніше». Хочете більше про зміцнення безпеки Microsoft 365 без шкоди для продуктивності користувачів? Ознайомтеся з ширшим посібником про посилення безпеки M365 із збереженням задоволеності користувачів, який охоплює Defender, Purview та умовний доступ у середовищах Entra ID.

Нижче наведено підсумок основних правил вибору, обробки та захисту токенів доступу та оновлення в будь-якій реалізації на базі Microsoft.

Головне про вибір і використання токенів

• Використовуйте токени доступу лише для негайного короткострокового доступу до ресурсів; токени оновлення застосовуйте лише там, де безперервні постійні сеанси є важливими і засоби контролю безпеки вже налаштовано.
• Зберігайте токени безпечно: використовуйте захищені платформою сховища, як-от HTTP-only cookie для веб, зв’язки ключів для мобільних і менеджери облікових даних для настільних застосунків. Ніколи не зберігайте чутливі токени у відкритому тексті або в localStorage браузера.
• Впроваджуйте ротацію та відкликання токенів, щоб під час кожного оновлення токени оновлення замінювалися, а старі ставали недійсними. Так скорочується вікно для атаки.
• Балансуйте тривалість сеансу та зручність для користувача; не робіть час життя токенів доступу настільки коротким, щоб користувачів постійно просили входити знову, але й не робіть його надто довгим, адже тоді витік токена створює зайві ризики.
• Контролюйте, керуйте та аудитуйте використання токенів— інтегруйте їх з такими інструментами, як Microsoft Defender і Purview, та застосовуйте Conditional Access для ризикованих сценаріїв входу. Якщо є підозра або виявлено компрометацію, негайно відкличте доступ.

Висновки та швидка перевірка знань

Розуміння різниці між токенами доступу та токенами оновлення — це не формальність у процесі OAuth 2. Саме це допомагає будувати безпечні та зручні сценарії на платформі ідентифікації Microsoft, зокрема в Entra ID. Знайти правильний баланс між короткими термінами життя токенів заради безпеки та довшими циклами оновлення заради зручності — справжнє мистецтво, особливо коли йдеться про сеанси користувачів на кількох пристроях або сервісах одночасно.

Готові до швидкої перевірки знань? Запитайте себе: як би ви обробляли закінчення терміну дії токена в застосунку з нестабільним інтернетом? Чи має токен оновлення взагалі потрапляти до ваших бекенд-мікросервісів? Якщо ця стаття була вам корисною або чимось вас навчила, поділіться своєю думкою: найкращі коментарі відкривають нові можливості та допомагають усій спільноті. Сподобалося? Залишайтеся з нами та продовжуйте розвивати свої навички безпеки!