Острови ідентичності: токени ACS проти Azure AD

By Mirko Peters · 2026-08-11

Раді знову вітати вас у блозі! Якщо ви коли-небудь дивилися на дорожню карту продукту й думали, чи варто вбудовувати власні функції комунікації безпосередньо у свій веб-застосунок о…

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

Titelbild: Identity Islands: Navigating ACS Tokens vs Azure AD

Раді вітати вас знову в блозі! Якщо ви колись проводили години над дорожньою картою продукту, намагаючись вирішити, чи варто вбудувати власні функції комунікації безпосередньо у ваш веб-застосунок, чи змусити користувачів працювати в корпоративному середовищі Microsoft Teams, знайте: ви не самотні. Неправильний вибір архітектури комунікації може призвести до величезного технічного боргу, несподіваних рахунків за ліцензії та труднощів із підключенням користувачів, які повністю гальмують впровадження. Щоб допомогти вам розібратися в цьому ландшафті, ми детально розглянемо фундаментальні відмінності між керуванням токенами, виданими застосунком, в Azure Communication Services (ACS) та використанням Azure AD для автентифікації співробітників, а також те, як зіставити ці дві окремі системи ідентичності під час побудови архітектур комунікації.

Цей матеріал безпосередньо доповнює наш останній епізод подкасту. Якщо ви хочете отримати детальний аудіоогляд цих реальних компромісів, обов’язково послухайте Azure Communication Services vs Teams APIs.

Для кого це

Керівники продуктів, які впроваджують клієнтський чат і дзвінки у веб- або мобільні застосунки
Архітектори платформи, які працюють із Microsoft 365, Azure AD і Graph
Керівники інженерних команд, які не хочуть отримати несподіваних проблем із відповідністю вимогам чи ліцензуванням

Головне

Ідентичність визначає все. ACS гнучкий для зовнішніх і анонімних користувачів; API Teams узгоджуються з Azure AD для внутрішніх користувачів, але додають труднощі з підключенням гостей.
Присутність — це розподільник. API Teams надають розширену присутність через Graph; ACS не має вбудованої присутності Teams, тож очікуйте власної синхронізації або компромісів.
Паритет чату має значення. Teams відображає функції клієнта (гілки, реакції, картки); ACS легкий і придатний для вбудовування, але недостатній інтерфейс доведеться створювати самостійно.
Існують обмеження для дзвінків. Взаємодія ACS і нарад Teams не є вбудованою; приєднання гостей через Teams часто вимагає запрошень гостей Azure AD.
Відповідність проти вартості. Teams успадковує можливості відповідності M365 (eDiscovery, DLP, юридичне утримання), але залежить від E3/E5 і преміум-функцій та реалій обмеження швидкості; ACS працює за моделлю оплати за використання, але ви відповідаєте за сховище, збереження та аудити.
Гібридна модель потужна, але дорога в експлуатації. Очікуйте проміжного програмного забезпечення для зіставлення ідентичностей, перетворення повідомлень, синхронізації присутності та застосування політик.

Короткі рекомендації: ACS, Teams чи гібрид?

Оберіть ACS, якщо вам потрібне безперешкодне масштабування B2C, анонімний чат або чат для гостей, швидкість SDK для мобільних і веб-застосунків та детальний контроль витрат, і ви готові самостійно керувати життєвим циклом токенів, сховищем, збереженням і аудитами.
Оберіть API Teams, якщо ваші основні користувачі — співробітники, яким потрібні присутність, чат із гілками, приєднання до нарад і вбудована відповідність вимогам за політиками клієнта, за умови що ви приймаєте витрати на ліцензування та дозволи Graph.
Оберіть гібридну модель, якщо вам потрібно передавати зовнішні розмови внутрішнім агентам у Teams або поєднувати публічний чат/дзвінки з можливостями відповідності та присутності Teams.

Реальні підводні камені (з практики)

Два острови ідентичності: токени ACS і об’єкти Azure AD → потрібен рівень зіставлення.
Податок на досвід гостей: запрошення гостей AAD уповільнюють швидкі B2C-процеси.
Невідповідність присутності: ACS не може «бачити», що співробітник зайнятий на нараді в Teams.
Обробка вкладень: Teams очікує OneDrive/SharePoint; ACS зазвичай використовує blob-сховища/URL-адреси.
Приховані обмеження: обмеження швидкості Graph і преміум-кінцеві точки можуть створити проблеми у великому масштабі.
Додатковий тягар відповідності для ACS: ви самостійно відповідаєте за шифрування, збереження, журнали аудиту та гарантії регіону зберігання.

Детальний розбір за функціями

Ідентичність і доступ

ACS: користувачі та токени, видані застосунком; чудово підходить для відвідувачів сайту та підрядників; ви самостійно відповідаєте за MFA, відкликання та строк дії.
API Teams: єдиний вхід Azure AD для співробітників; гості потребують запрошень і згоди, а також узгодження з політиками клієнта.

Присутність

API Teams: розширена миттєва присутність через Graph у межах клієнта.
ACS: вбудованої присутності Teams немає; потрібні власна телеметрія та синхронізація.

Чат і UX

API Teams: гілки, реакції, картки, відповіді та файли у тексті — паритет із Teams.
ACS: базовий обмін повідомленнями; гілки, пошук, власні емодзі та збереження історії доведеться додавати самостійно.

Дзвінки/наради

ACS: вбудовуйте голос і відео у свій застосунок; добре підходить для публічного доступу; самостійно усувайте неполадки медіашляхів.
Teams APIs: безшовно працюють для користувачів клієнта; зовнішнє приєднання зазвичай передбачає онбординг гостей AAD.

SDK & DevEx

ACS: уніфіковані SDK для Web, iOS і Android; швидко вбудовуються.
Teams/Graph/Bot: потужно, але крива навчання крутіша (дозволи, вебхуки, пагінація).

Відповідність вимогам і ліцензування

Teams: eDiscovery, DLP, юридичне утримання та резидентність даних уже вбудовані; оплата через ліцензії M365 і можливі преміум-функції чи обмеження.
ACS: оплата за використанням; ви самі відповідаєте за місце зберігання, політику збереження, SIEM і експорт аудиту.

Референсні архітектури (ментальні моделі)

Портал B2C (насамперед ACS): чат і дзвінки ACS -> ваше сховище та збереження -> необов'язкова передача в Teams через бота або канал для агентів.
Внутрішня служба підтримки (насамперед Teams): чат Teams і бот + присутність через Graph -> єдиний вхід для співробітників (SSO) -> необов'язкове публічне приймання звернень через форми або онбординг гостей.
Гібридний міст: ACS для публічного віджета <-> проміжне ПЗ (відповідність ідентифікаторів, перетворення повідомлень, синхронізація присутності, хуки відповідності) <-> канал Teams і досвід агента.

Контрольний список для побудови

Визначте основного користувача: співробітники, підрядники чи публічні користувачі.
Вирішіть, де зберігаються дані, і хто відповідає за збереження та аудит.
Опишіть потоки ідентифікації (SSO, гості, анонімні користувачі) до написання коду.
Перевірте вимоги до присутності на ранньому етапі — не відкладайте це на потім.
Проведіть навантажувальне тестування лімітів Graph і пропускної здатності повідомлень та дзвінків ACS.
Закладіть бюджет на ліцензії проти експлуатації (проміжне ПЗ, аудит, моніторинг).
Продумайте відкат і вихід, якщо ваші потреби зміняться наступного кварталу.

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

Чи можуть користувачі ACS приєднатися до наради Teams напряму? Ні, напряму не можуть; очікуйте проміжний міст або потік гостей AAD.
Чи потрібні ліцензії M365 для користувачів ACS? Ні, ACS тарифікується за використанням.
Чи працюють Teams APIs з зовнішніми анонімними користувачами? Не надійно; зазвичай потрібен онбординг гостей AAD.
Чи доступна присутність з ACS? Не для користувачів Teams; потрібна власна синхронізація або обхідні рішення.

Кроки дій

Визначте три головні вимоги: (наприклад, анонімний чат, присутність у Teams, eDiscovery).
Проведіть пілотні тести у два напрямки: PoC на ACS для публічного чату та PoC на Teams для внутрішніх агентів.
Якщо потрібні обидва варіанти, сплануйте MVP проміжного ПЗ: відповідність ідентифікаторів, пересилання повідомлень, мінімальну синхронізацію присутності та журналювання аудиту.
Узгодьте бюджет: місця M365 проти використання ACS плюс штат для забезпечення відповідності.

Наостанок зазначу: побудова архітектури, яка успішно з'єднує «острови ідентичності» між Azure Communication Services і Azure AD, потребує чіткого розуміння вашої аудиторії. Створюєте ви відкритий споживчий портал чи внутрішню службу підтримки для підприємства, тримайте ідентифікацію в центрі уваги, і це заощадить вам багато клопоту надалі. Для глибшого обговорення цих рішень послухайте супровідний епізод на «Azure Communication Services vs Teams APIs» і підписуйтеся, щоб бути в курсі всього, що стосується Microsoft 365 та архітектури Azure!