Identity Islands: навигация между токенами 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 гибок для внешних и анонимных пользователей; Teams APIs используют Azure AD для внутренних пользователей, но добавляют сложности с онбордингом гостей.
Присутствие разделяет подходы. Teams APIs предоставляют богатые данные о присутствии через Graph; ACS не имеет встроенного присутствия Teams, поэтому ожидайте пользовательской синхронизации или компромиссов.
Паритет функций чата важен. Teams повторяет функции клиента (треды, реакции, карточки); ACS лёгкий и встраиваемый, но недостающий UX придётся создавать самостоятельно.
Есть границы для звонков. Взаимодействие ACS и собраний Teams не является встроенным; подключение гостей через Teams часто требует приглашений гостей в Azure AD.
Соответствие требованиям против стоимости. Teams наследует соответствие требованиям Microsoft 365 (eDiscovery, DLP, юридическое удержание), но работает на E3/E5 с премиум-функциями и реалиями ограничения частоты запросов; ACS оплачивается по факту использования, но хранение, политика хранения и аудит остаются на вашей стороне.
Гибридная модель мощна и дорога в эксплуатации. Ожидайте промежуточный слой для сопоставления идентификаторов, преобразования сообщений, синхронизации присутствия и применения политик.

Краткое руководство: ACS, Teams или гибрид?

Выбирайте ACS, если вам нужен беспроблемный масштаб B2C, анонимный или гостевой чат, скорость мобильных и веб-SDK и гибкий контроль затрат, и вы готовы самостоятельно управлять жизненным циклом токенов, хранением, политикой хранения и аудитом.
Выбирайте Teams APIs, если ваши основные пользователи — сотрудники, которым нужны присутствие, треды, подключение к собраниям и встроенное соответствие требованиям в рамках политик клиента, при этом вы принимаете расходы на лицензирование и разрешения Graph.
Переходите на гибрид, когда нужно передавать внешние диалоги внутренним агентам в Teams или сочетать публичный чат и звонки с соответствием требованиям и присутствием Teams.

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

Два изолированных мира идентификации: токены ACS и объекты Azure AD -> требуется уровень сопоставления.
Налог на гостевой опыт: приглашения гостей в AAD замедляют быстрые B2C-сценарии.
Расхождение присутствия: ACS не может «увидеть», что сотрудник занят на собрании в Teams.
Работа с вложениями: Teams ожидает OneDrive/SharePoint, тогда как ACS часто использует blob-объекты и URL-адреса.
Скрытые ограничения: ограничение частоты запросов Graph и премиум-эндпоинты могут стать проблемой при масштабировании.
Дополнительная нагрузка по соответствию требованиям при использовании ACS: шифрование, хранение, журналы аудита и гарантии региона обеспечиваете вы.

Разбор по функциям

Идентификация и доступ

ACS: пользователи и токены, выдаваемые приложением; отлично подходит для посетителей сайта и подрядчиков; MFA, отзыв и срок действия управляете вы.
Teams APIs: SSO через Azure AD для сотрудников; для гостей нужны приглашения и согласие, а также согласование с политикой клиента.

Присутствие

Teams APIs: богатое мгновенное присутствие в рамках клиента через Graph.
ACS: встроенного присутствия Teams нет; требуется собственная телеметрия и синхронизация.

Чат и UX

Teams APIs: треды, реакции, карточки, ответы, файлы в строке — паритет с Teams.
ACS: облегчённый обмен сообщениями; треды, поиск, пользовательские эмодзи и хранение придётся добавлять самостоятельно.

Звонки и собрания

ACS: встраивайте голос и видео в своё приложение; отлично подходит для публичного доступа; диагностику медиапутей придётся вести самостоятельно.
Teams API: бесшовно работают для пользователей клиента; подключение внешних участников обычно требует оформления гостевой учётной записи в AAD.

SDK и DevEx

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

Соответствие требованиям и лицензирование

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

Эталонные архитектуры (ментальные модели)

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

Контрольный список для разработки

Определите основного пользователя: сотрудники, подрядчики или публичные пользователи.
Решите, где хранятся данные, и кто отвечает за политику хранения и аудит.
Опишите сценарии идентификации (единый вход, гости, анонимные пользователи) до того, как начнёте писать код.
Проверьте требования к присутствию на раннем этапе — не добавляйте его потом «сбоку».
Проведите нагрузочное тестирование ограничений Graph и пропускной способности сообщений и звонков ACS.
Заложите в бюджет лицензии и эксплуатацию (промежуточное ПО, аудит, мониторинг).
Продумайте откат и выход, если ваши потребности изменятся в следующем квартале.

Краткий FAQ

Могут ли пользователи ACS напрямую подключиться к собранию Teams? Напрямую нет; ожидайте промежуточного моста или сценария с гостевой учётной записью AAD.
Нужны ли лицензии M365 для пользователей ACS? Нет, ACS оплачивается по факту использования.
Могут ли Teams API работать с внешними анонимными пользователями? Не напрямую; обычно требуется оформление гостевой учётной записи AAD.
Доступно ли присутствие в ACS? Не для пользователей Teams; потребуется собственная синхронизация или обходные решения.

Шаги действий

Определите три главных требования: например, анонимный чат, присутствие в Teams, eDiscovery.
Проведите спайк в два трека: PoC на ACS для публичного чата и PoC на Teams для внутренних агентов.
Если нужны оба варианта, спланируйте MVP промежуточного ПО: сопоставление идентификаторов, передача сообщений, минимальная синхронизация присутствия и журналирование аудита.
Согласуйте бюджет: места M365 против использования ACS и штат специалистов по эксплуатации и соответствию требованиям.

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