Ilhas de identidade: como navegar entre tokens do ACS e o 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

Bem-vindo de volta ao blog! Se você já ficou olhando para um roadmap de produto, tentando decidir se deve incorporar recursos de comunicação personalizados diretamente na sua aplicação web ou levar seus usuários para o ambiente corporativo do Microsoft Teams, saiba que você não está sozinho. Escolher a arquitetura de comunicação errada pode gerar uma enorme dívida técnica, contas de licenciamento inesperadas e atritos no onboarding de usuários que travam completamente a adoção. Para ajudar você a entender esse cenário, vamos mergulhar nas diferenças fundamentais entre gerenciar tokens emitidos pela aplicação no Azure Communication Services (ACS) e depender do Azure AD para autenticação de funcionários, além de como mapear esses dois sistemas de identidade separados ao construir arquiteturas de comunicação.

Este mergulho complementa diretamente nosso episódio mais recente do podcast. Se você quer um detalhamento em áudio completo sobre esses trade-offs do mundo real, não deixe de conferir Azure Communication Services vs Teams APIs.

Para quem é este conteúdo

Líderes de produto que lançam chat/chamadas para clientes em aplicações web ou mobile
Arquitetos de plataforma que trabalham com Microsoft 365, Azure AD e Graph
Gerentes de engenharia que não querem incêndios inesperados de conformidade ou licenciamento

Principais conclusões

A identidade define tudo. O ACS é flexível para usuários externos/anônimos; as APIs do Teams se alinham ao Azure AD para usuários internos, mas adicionam atrito no onboarding de convidados.
A presença é um divisor. As APIs do Teams expõem presença rica via Graph; o ACS não tem presença nativa do Teams, então espere sincronização personalizada ou concessões.
A paridade de chat importa. O Teams replica os recursos do cliente (threads, reações, cartões); o ACS é enxuto e incorporável, mas você mesmo vai construir a experiência de usuário que faltar.
Existem limites para chamadas. A interoperabilidade entre ACS <-> reunião do Teams não é nativa; a entrada de convidados via Teams normalmente exige convites de convidado no Azure AD.
Conformidade versus custo. O Teams herda a conformidade do M365 (eDiscovery, DLP, retenção legal), mas depende de E3/E5 + recursos premium e das limitações de throttling; o ACS é pago conforme o uso, porém você é responsável pelo armazenamento, pela retenção e pelas auditorias.
O modelo híbrido é poderoso, mas caro em operação. Espere precisar de middleware para mapeamento de identidade, transformação de mensagens, sincronização de presença e aplicação de políticas.

Orientação rápida: ACS, Teams ou híbrido?

Escolha o ACS se você precisa de escala B2C sem atrito, chat anônimo/convidado, velocidade dos SDKs para mobile/Web e controle granular de custos, e está disposto a assumir o ciclo de vida dos tokens, o armazenamento, a retenção e as auditorias.
Escolha as APIs do Teams se seus principais usuários são funcionários que precisam de presença, chat em threads, entrada em reuniões e conformidade nativa sob as políticas do locatário, aceitando o custo de licenciamento e de permissões do Graph.
Adote o híbrido quando você precisar expor conversas externas a agentes internos no Teams ou combinar chat/chamadas públicos com a conformidade e a presença do Teams.

Armadilhas do mundo real (da prática)

Duas ilhas de identidade: tokens do ACS versus objetos do Azure AD -> é necessária uma camada de mapeamento.
Custo da experiência de convidado: convites de convidado no AAD desaceleram fluxos B2C rápidos.
Descompasso de presença: o ACS não consegue "ver" que um atendente está ocupado em uma reunião do Teams.
Tratamento de anexos: o Teams espera OneDrive/SharePoint; o ACS geralmente usa blobs/URLs.
Limites ocultos: o throttling do Graph e os endpoints premium podem causar problemas em escala.
Carga de conformidade no ACS: você é responsável pela criptografia, pela retenção, pelas trilhas de auditoria e pelas garantias de região.

Comparativo recurso a recurso

Identidade e acesso

ACS: usuários/tokens emitidos pela aplicação, ótimo para visitantes do site e prestadores; você é responsável por MFA, revogação e expiração.
APIs do Teams: SSO do Azure AD para funcionários; convidados exigem convites/consentimento e alinhamento com as políticas do locatário.

Presença

APIs do Teams: presença rica e instantânea via Graph em todo o locatário.
ACS: não há presença nativa do Teams; é necessária telemetria/sincronização personalizada.

Chat e UX

APIs do Teams: threads, reações, cartões, respostas e arquivos embutidos—paridade com o Teams.
ACS: mensagens enxutas; você mesmo adiciona threads, busca, emojis personalizados e persistência.

Chamadas/Reuniões

ACS: incorpore voz/vídeo no seu app; ótimo para acesso público; solucione os problemas de caminho de mídia por conta própria.
APIs do Teams: integração perfeita para usuários do locatário; a participação externa geralmente exige a integração de convidados do AAD.

SDK & DevEx

ACS: SDKs unificados para Web/iOS/Android; rápidos de incorporar.
Teams/Graph/Bot: poderosos, mas com curva de aprendizado mais íngreme (permissões, webhooks, paginação).

Conformidade & Licenciamento

Teams: eDiscovery, DLP, retenção legal e residência de dados já integrados; paga-se por meio das licenças do M365 e possíveis recursos premium/limites.
ACS: cobrança baseada no uso; você define o local de armazenamento, a retenção, o SIEM e as exportações de auditoria.

Arquiteturas de Referência (Modelos Mentais)

Portal B2C (com ACS em primeiro lugar): chat/chamadas do ACS -> seu armazenamento/retenção -> repasse opcional para o Teams via bot/canal para os agentes.
Helpdesk Interno (com Teams em primeiro lugar): chat/bot do Teams + presença do Graph -> SSO para a equipe -> entrada pública opcional via formulários ou integração de convidados.
Ponte Híbrida: ACS para o widget público <-> middleware (mapeamento de IDs, transformação de mensagens, sincronização de presença, ganchos de conformidade) <-> canal do Teams/experiência do agente.

Checklist de Construção

Defina o usuário principal: funcionários, prestadores de serviço ou público.
Decida onde os dados ficam e quem é responsável pela retenção e pelas auditorias.
Mapeie os fluxos de identidade (SSO, convidados, anônimos) antes de escrever código.
Valide os requisitos de presença logo no início; não a deixe para depois.
Faça testes de carga nos limites do Graph e na capacidade de mensagens e chamadas do ACS.
Planeje o orçamento de licenças versus operação (middleware, auditorias, monitoramento).
Planeje o rollback/saída caso suas necessidades mudem no próximo trimestre.

Mini FAQ

Usuários do ACS podem participar de uma reunião do Teams nativamente? Não diretamente; espere uma ponte ou um fluxo de convidado do AAD.
Preciso de licenças do M365 para usuários do ACS? Não, o ACS é baseado no uso.
As APIs do Teams lidam com usuários externos anônimos? Não de forma adequada; geralmente exige a integração de convidados do AAD.
A presença está disponível com o ACS? Não para usuários do Teams; exige sincronização personalizada ou soluções alternativas.

Etapas de Ação

Identifique seus 3 requisitos essenciais: (por exemplo, chat anônimo, presença do Teams, eDiscovery).
Execute um spike em 2 trilhas: PoC do ACS para chat público; PoC do Teams para agentes internos.
Se ambos forem necessários, defina um MVP de middleware: mapeamento de identidade, repasse de mensagens, sincronização mínima de presença e registro de auditoria.
Alinhe o orçamento: licenças do M365 versus uso do ACS + equipe de operações para conformidade.

Para concluir, projetar uma arquitetura que faça a ponte entre ilhas de identidade do Azure Communication Services e do Azure AD exige uma compreensão clara do seu público. Seja você está criando um portal de consumo aberto ou um helpdesk corporativo interno, manter a identidade em primeiro plano vai poupar muitas dores de cabeça no futuro. Para uma discussão mais aprofundada sobre essas escolhas, não deixe de ouvir o episódio complementar em Azure Communication Services vs Teams APIs e assine para ficar por dentro de tudo sobre Microsoft 365 e arquitetura do Azure!