Islas de identidad: navegar entre los tokens de ACS y Azure AD

By Mirko Peters · 2026-08-11

¡Bienvenido de nuevo al blog! Si alguna vez te has quedado mirando una hoja de ruta de producto, intentando decidir si incrustar funciones de comunicación personalizadas directamente en tu aplicación web o…

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

Titelbild: Identity Islands: Navigating ACS Tokens vs Azure AD

¡Bienvenido de nuevo al blog! Si alguna vez has mirado una hoja de ruta de producto intentando decidir si integrar funciones de comunicación personalizadas directamente en tu aplicación web o obligar a tus usuarios a entrar en el ecosistema empresarial de Microsoft Teams, no estás solo. Elegir la arquitectura de comunicación equivocada puede generar una enorme deuda técnica, facturas de licencias inesperadas y fricciones en la incorporación de usuarios que frenan por completo la adopción. Para ayudarte a entender este panorama, vamos a analizar en profundidad las diferencias fundamentales entre gestionar tokens emitidos por la aplicación en Azure Communication Services (ACS) y depender de Azure AD para la autenticación de empleados, así como la forma de relacionar estos dos sistemas de identidad independientes al diseñar arquitecturas de comunicación.

Este análisis complementa directamente nuestro último episodio del podcast. Si quieres un desglose completo en audio de estas compensaciones del mundo real, no dejes de consultar Azure Communication Services vs Teams APIs.

Para quién es esto

Responsables de producto que lanzan chat o llamadas de clientes en aplicaciones web o móviles
Arquitectos de plataforma que navegan por Microsoft 365, Azure AD y Graph
Gerentes de ingeniería que no quieren incendios inesperados en cumplimiento normativo o licencias

Puntos clave

La identidad lo condiciona todo. ACS es flexible para usuarios externos o anónimos; las API de Teams se alinean con Azure AD para usuarios internos, pero añaden fricción en la incorporación de invitados.
La presencia marca la diferencia. Las API de Teams exponen una presencia completa a través de Graph; ACS no tiene presencia nativa de Teams: prepárate para sincronizaciones personalizadas o compromisos.
La paridad en el chat importa. Teams replica las funciones de sus clientes (hilos, reacciones, tarjetas); ACS es ligero e integrable, pero tendrás que construir tú mismo la experiencia de usuario que falte.
Existen límites en las llamadas. La interoperabilidad entre ACS y las reuniones de Teams no es nativa; los invitados que se unen a través de Teams suelen requerir invitaciones de invitado de Azure AD.
Cumplimiento frente a coste. Teams hereda el cumplimiento de Microsoft 365 (eDiscovery, DLP, retención legal), pero depende de E3/E5 y de funciones premium, además de las limitaciones de throttling; ACS funciona con pago por uso, pero tú asumes el almacenamiento, la retención y las auditorías.
El modelo híbrido es potente, pero costoso en operaciones. Espera necesitar middleware para la asignación de identidades, la transformación de mensajes, la sincronización de presencia y la aplicación de directivas.

Orientación rápida: ¿ACS, Teams o híbrido?

Elige ACS si necesitas una escalabilidad B2C sin fricciones, chat anónimo o de invitados, rapidez con los SDK móviles o web y un control detallado de costes, y estás dispuesto a asumir la gestión del ciclo de vida de los tokens, el almacenamiento, la retención y las auditorías.
Elige las API de Teams si tus usuarios principales son empleados que necesitan presencia, chat con hilos, unirse a reuniones y cumplimiento integrado bajo las directivas del inquilino, asumiendo la sobrecarga de licencias y permisos de Graph.
Opta por lo híbrido cuando debas mostrar conversaciones externas a agentes internos en Teams o combinar chats y llamadas públicas con el cumplimiento y la presencia de Teams.

Inconvenientes reales (desde el terreno)

Dos islas de identidad: tokens de ACS frente a objetos de Azure AD -> se necesita una capa de asignación.
Coste de la experiencia de invitado: las invitaciones de invitado de AAD ralentizan los flujos B2C rápidos.
Desajuste de presencia: ACS no puede "ver" que un agente está ocupado en una reunión de Teams.
Gestión de adjuntos: Teams espera OneDrive/SharePoint; ACS suele usar blobs/URL.
Límites ocultos: el throttling de Graph y los endpoints premium pueden causar problemas a gran escala.
Carga de cumplimiento en ACS: tú asumes el cifrado, la retención, los registros de auditoría y las garantías de región.

Desglose funcionalidad por funcionalidad

Identidad y acceso

ACS: usuarios y tokens emitidos por la aplicación, ideales para visitantes del sitio web o contratistas; tú gestionas la MFA, la revocación y la caducidad.
API de Teams: SSO de Azure AD para el personal; los invitados requieren invitaciones, consentimiento y alineación con las directivas del inquilino.

Presencia

API de Teams: presencia rica e instantánea a través de Graph en todo el inquilino.
ACS: no tiene presencia nativa de Teams; requiere telemetría y sincronización personalizadas.

Chat y experiencia de usuario

API de Teams: hilos, reacciones, tarjetas, respuestas y archivos integrados en la conversación, con una paridad similar a la de Teams.
ACS: mensajería ligera; tendrás que añadir tú mismo hilos, búsqueda, emojis personalizados y persistencia.

Llamadas/Reuniones

ACS: Integra voz y vídeo en tu aplicación; es ideal para el acceso público, pero tendrás que solucionar tú mismo los problemas de las rutas de medios.
API de Teams: Integración perfecta para los usuarios del inquilino; la unión de externos suele implicar la incorporación de invitados de AAD.

SDK y experiencia de desarrollo

ACS: SDK unificados para Web, iOS y Android; rápidos de integrar.
Teams/Graph/Bot: Muy potentes, pero con una curva de aprendizaje más pronunciada (permisos, webhooks, paginación).

Cumplimiento y licencias

Teams: eDiscovery, DLP, retención legal y residencia de datos integrados de serie; se paga mediante licencias de M365 y posibles funciones premium o límites.
ACS: Facturación basada en el uso; tú decides la ubicación del almacenamiento, la retención, el SIEM y las exportaciones de auditoría.

Arquitecturas de referencia (modelos mentales)

Portal B2C (con ACS como base): chat y llamadas de ACS -> tu almacenamiento y retención -> reenvío opcional a Teams mediante un bot o canal para los agentes.
Mesa de ayuda interna (con Teams como base): chat y bot de Teams + presencia de Graph -> SSO para el personal -> entrada pública opcional mediante formularios o incorporación de invitados.
Puente híbrido: ACS para el widget público <-> middleware (mapeo de ID, transformación de mensajes, sincronización de presencia, hooks de cumplimiento) <-> experiencia de canal y agente en Teams.

Lista de verificación para la creación

Define el usuario principal: empleados, contratistas o público.
Decide dónde residen los datos y quién es responsable de la retención y las auditorías.
Mapea los flujos de identidad (SSO, invitados, anónimos) antes de escribir código.
Valida los requisitos de presencia desde el principio: no lo dejes para más tarde.
Realiza pruebas de carga de los límites de Graph y del rendimiento de mensajes y llamadas de ACS.
Presupuesta las licencias frente a las operaciones (middleware, auditorías, monitorización).
Planifica el rollback o la salida por si tus necesidades cambian el próximo trimestre.

Mini preguntas frecuentes

¿Pueden los usuarios de ACS unirse de forma nativa a una reunión de Teams? No directamente; espera un puente o un flujo de invitados de AAD.
¿Necesito licencias de M365 para los usuarios de ACS? No, ACS se factura según el uso.
¿Las API de Teams gestionan usuarios anónimos externos? No de forma limpia; normalmente requieren la incorporación de invitados de AAD.
¿Está disponible la presencia con ACS? No para los usuarios de Teams; requiere sincronización personalizada o soluciones alternativas.

Pasos de acción

Identifica tus 3 requisitos imprescindibles (por ejemplo, chat anónimo, presencia de Teams, eDiscovery).
Ejecuta una prueba de concepto en dos vías: una PoC de ACS para el chat público y una PoC de Teams para los agentes internos.
Si se necesitan ambas, define un MVP de middleware: mapeo de identidades, reenvío de mensajes, sincronización mínima de presencia y registro de auditoría.
Alinea el presupuesto: puestos de M365 frente al uso de ACS más el personal de operaciones necesario para el cumplimiento.

Para terminar, diseñar una arquitectura que tienda puentes entre las islas de identidad de Azure Communication Services y Azure AD requiere tener muy claro quién es tu audiencia. Tanto si construyes un portal de consumo abierto como una mesa de ayuda empresarial interna, mantener la identidad en primer plano te ahorrará muchos quebraderos de cabeza más adelante. Para profundizar en estas decisiones, escucha el episodio complementario en Azure Communication Services vs Teams APIs y suscríbete para estar al día de todo lo relacionado con Microsoft 365 y la arquitectura de Azure.