Azure Entra ID: App Registrations, Service Principals та Enterprise Apps

Зізнайтеся, скільки разів ви читали офіційну документацію Microsoft і ловили себе на думці, що після прочитаного запитань стало ще більше? Особливо це стосується Entra ID (старого доброго Azure AD).

Коли ми будуємо мікросервісну архітектуру, налаштовуємо CI/CD пайплайни або просто пояснюємо колегам, як правильно інтегрувати новий сервіс, рано чи пізно доводиться розбиратися з трьома сутностями: App Registrations, Service Principals та Enterprise Applications.

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

Для початку — трохи бази (OAuth 2.0 та OIDC)

Перш ніж лізти в Azure, давайте згадаємо, як взагалі працює сучасний безпечний доступ. У нас є два кити:

• OpenID Connect (OIDC) — це про те, хто ви такий. Це аутентифікація.
• OAuth 2.0 — це про те, що вам дозволено робити. Це авторизація (надання прав діяти від вашого імені).

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

Тому наш застосунок стукає до сервера авторизації (Entra ID), каже: «Ось мій Client ID, мені потрібні такі-то права (Scopes)». Користувач логіниться, тисне «Дозволяю» (надає Consent), і додаток отримує тимчасові токени — Access Token та Refresh Token. Усе, облікові дані в безпеці, а додаток робить лише те, на що йому дали дозвіл.

Перекладаємо на мову Azure

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

1. App Registration (Реєстрація додатку) — це «Креслення»

Це глобальний паспорт вашого додатка. Ви створюєте його у своєму «домашньому» (home) тенанті.

Саме сюди приходять розробники, щоб сказати Azure: «Гей, у нас є нова апка». Тут ви отримуєте той самий Client ID і прописуєте, які саме дозволи вашому коду потрібні на глобальному рівні (наприклад, читати користувачів через Microsoft Graph).

Головне: Це просто глобальний опис додатка. App Registration — це глобальний опис в межах одного tenant

2. Service Principal — це «Робітник»

Якщо App Registration — це креслення або клас в об’єктно-орієнтованому програмуванні, то Service Principal — це конкретний екземпляр (об’єкт) цього класу, який «живе» і працює у вашому тенанті.

Коли ви реєструєте додаток, Azure під капотом автоматично створює для нього Service Principal у вашому тенанті. Саме на Service Principal вішаються реальні права доступу (RBAC) до ресурсів.

Фішка в тому: якщо ваш додаток багатотенантний і хтось із зовсім іншої компанії вирішить його заюзати, у нього в Azure створюється свій Service Principal, який посилається на вашу єдину глобальну App Registration.

3. Enterprise Applications — це «Вітрина»

Не шукайте тут якоїсь глибокої архітектурної магії. Enterprise Apps — це просто зручна менюшка на порталі Azure.

Це список усіх Service Principals (як ваших внутрішніх, так і сторонніх), які зараз мають якісь права у вашому тенанті. Це ваша панель керування, де ви можете подивитися: «Так, кому ми тут понадавали доступів і на що саме вони погодилися?».

Підсумок

Щоб назавжди перестати плутатися:

• App Registration = Глобальний опис або паспорт (генерує Client ID).
• Service Principal = Локальний представник у конкретному тенанті (саме йому ми видаємо реальні права).
• Enterprise Apps = В’юшка на порталі, де лежать усі ці локальні представники.

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