Isole di identità: navigare tra token ACS e 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

Bentornato sul blog! Se ti sei mai trovato a fissare una roadmap di prodotto chiedendoti se integrare funzionalità di comunicazione personalizzate direttamente nella tua web app oppure costringere gli utenti a entrare nell'ecosistema aziendale di Microsoft Teams, non sei il solo. Scegliere l'architettura di comunicazione sbagliata può portare a un enorme debito tecnico, a fatture di licenze inattese e ad attriti nell'onboarding degli utenti che bloccano completamente l'adozione. Per aiutarti a orientarti in questo scenario, approfondiamo le differenze di fondo tra la gestione dei token emessi dall'app in Azure Communication Services (ACS) e l'uso di Azure AD per l'autenticazione dei dipendenti, oltre a come mappare questi due sistemi di identità separati quando si progettano architetture di comunicazione.

Questo approfondimento è il complemento diretto del nostro ultimo episodio del podcast. Se vuoi una panoramica audio completa di questi compromessi reali, non perdere Azure Communication Services vs Teams APIs.

A chi è rivolto

Product leader che rilasciano chat e chiamate con clienti in app web o mobile
Platform architect che lavorano con Microsoft 365, Azure AD e Graph
Engineering manager che non vogliono brutte sorprese su conformità o licenze

Punti chiave

L'identità guida tutto. ACS è flessibile per utenti esterni o anonimi; le API di Teams si allineano ad Azure AD per gli utenti interni, ma aggiungono attrito nell'onboarding degli ospiti.
La presenza fa la differenza. Le API di Teams espongono una presenza ricca tramite Graph; ACS non ha una presenza nativa di Teams, quindi aspettati sincronizzazioni personalizzate o compromessi.
La parità delle chat conta. Teams replica le funzionalità del client (thread, reazioni, schede); ACS è essenziale e integrabile, ma l'interfaccia mancante dovrai costruirla tu.
Esistono limiti nelle chiamate. L'interoperabilità tra ACS e le riunioni di Teams non è nativa; l'accesso degli ospiti tramite Teams richiede spesso inviti guest di Azure AD.
Conformità contro costi. Teams eredita la conformità di Microsoft 365 (eDiscovery, DLP, blocco per uso legale), ma comporta licenze E3/E5, funzionalità premium e limiti di throttling; ACS si paga a consumo, però la gestione di archiviazione, conservazione e audit è a tuo carico.
L'approccio ibrido è potente, ma costoso in termini operativi. Aspettati middleware per la mappatura delle identità, la trasformazione dei messaggi, la sincronizzazione della presenza e l'applicazione dei criteri.

Indicazioni rapide: ACS, Teams o ibrido?

Scegli ACS se ti servono scalabilità B2C senza attriti, chat anonime o per ospiti, rapidità con gli SDK mobile e web e un controllo granulare dei costi, e sei disposto a gestire il ciclo di vita dei token, l'archiviazione, la conservazione e gli audit.
Scegli le API di Teams se i tuoi utenti principali sono dipendenti che hanno bisogno di presenza, chat con thread, accesso alle riunioni e conformità integrata secondo i criteri del tenant, accettando il carico di licenze e autorizzazioni Graph.
Scegli l'ibrido quando devi portare conversazioni esterne agli agenti interni in Teams oppure combinare chat e chiamate pubbliche con la conformità e la presenza di Teams.

Problemi reali (dal campo)

Due isole di identità: token ACS e oggetti di Azure AD richiedono un livello di mappatura.
Costo dell'esperienza ospite: gli inviti guest di AAD rallentano i flussi B2C veloci.
Disallineamento della presenza: ACS non può "vedere" che un operatore è occupato in una riunione di Teams.
Gestione degli allegati: Teams si appoggia a OneDrive e SharePoint; ACS spesso usa blob e URL.
Limiti nascosti: il throttling di Graph e gli endpoint premium possono creare problemi su larga scala.
Carico di conformità su ACS: crittografia, conservazione, tracce di audit e garanzie sulla regione sono di tua responsabilità.

Confronto funzione per funzione

Identità e accesso

ACS: utenti e token emessi dall'app, ideali per visitatori del sito o collaboratori esterni; gestisci tu MFA, revoca e scadenza.
API di Teams: SSO di Azure AD per il personale; gli ospiti richiedono inviti, consenso e allineamento con i criteri del tenant.

Presenza

API di Teams: presenza ricca e immediata tramite Graph in tutto il tenant.
ACS: nessuna presenza nativa di Teams; richiede telemetria o sincronizzazione personalizzata.

Chat e UX

API di Teams: thread, reazioni, schede, risposte, file inline, con una parità simile a Teams.
ACS: messaggistica essenziale; thread, ricerca, emoji personalizzate e persistenza vanno aggiunti da te.

Chiamate/Riunioni

ACS: incorpori voce e video nella tua app; ottimo per l'accesso pubblico; la risoluzione dei problemi sui percorsi multimediali è a tuo carico.
Teams API: integrazione fluida per gli utenti del tenant; l'accesso di utenti esterni richiede spesso l'onboarding come guest in AAD.

SDK & DevEx

ACS: SDK unificati per Web, iOS e Android; integrazione rapida.
Teams/Graph/Bot: potenti ma con una curva di apprendimento più ripida (autorizzazioni, webhook, paginazione).

Conformità e licenze

Teams: eDiscovery, DLP, blocco per uso legale e residenza dei dati sono già integrati; si paga tramite le licenze M365, con possibili funzionalità premium e limiti.
ACS: fatturazione basata sull'utilizzo; sei tu a gestire la posizione di archiviazione, la conservazione, il SIEM e le esportazioni dei log di controllo.

Architetture di riferimento (modelli mentali)

Portale B2C (ACS-first): chat/chiamate ACS -> il tuo archivio/conservazione -> eventuale inoltro verso Teams tramite bot/canale per gli operatori.
Helpdesk interno (Teams-first): chat/bot Teams + presenza tramite Graph -> SSO per il personale -> eventuale acquisizione pubblica tramite moduli o onboarding di guest.
Ponte ibrido: ACS per il widget pubblico <-> middleware (mappatura ID, trasformazione dei messaggi, sincronizzazione della presenza, hook di conformità) <-> canale Teams/esperienza dell'agente.

Checklist di sviluppo

Definisci l'utente principale: dipendenti, collaboratori esterni o utenti pubblici.
Decidi dove risiedono i dati e chi è responsabile di conservazione e audit.
Mappa i flussi di identità (SSO, guest, anonimi) prima di scrivere il codice.
Verifica subito i requisiti di presenza: non aggiungerli in un secondo momento.
Esegui test di carico sui limiti di Graph e sulla capacità di messaggi e chiamate di ACS.
Prevedi il budget per licenze e operatività (middleware, audit, monitoraggio).
Pianifica il rollback/l'uscita nel caso in cui le tue esigenze cambino il prossimo trimestre.

Mini FAQ

Gli utenti ACS possono partecipare nativamente a una riunione Teams? Non direttamente; prevedi un ponte o un flusso di guest in AAD.
Servono licenze M365 per gli utenti ACS? No: ACS si basa sull'utilizzo.
Le Teams API gestiscono utenti esterni anonimi? Non in modo lineare; di solito richiedono l'onboarding come guest in AAD.
La presenza è disponibile con ACS? Non per gli utenti Teams: richiede sincronizzazioni personalizzate o soluzioni alternative.

Passi operativi

Individua i tuoi 3 requisiti imprescindibili (ad esempio: chat anonima, presenza in Teams, eDiscovery).
Esegui uno spike su due binari: PoC ACS per la chat pubblica; PoC Teams per gli agenti interni.
Se servono entrambi, definisci un MVP di middleware: mappatura delle identità, inoltro dei messaggi, sincronizzazione minima della presenza e registrazione degli audit.
Allinea il budget: postazioni M365 rispetto all'utilizzo di ACS più il personale operativo per la conformità.

In conclusione, progettare un'architettura che colleghi con successo le isole di identità tra Azure Communication Services e Azure AD richiede una chiara comprensione del tuo pubblico. Che tu stia costruendo un portale consumer aperto o un helpdesk aziendale interno, mettere l'identità al centro ti risparmierà un sacco di grattacapi in futuro. Per un approfondimento su queste scelte, ascolta l'episodio collegato su Azure Communication Services vs Teams APIs e iscriviti per restare al passo con tutto ciò che riguarda Microsoft 365 e l'architettura di Azure!