Identity Islands: ACS-Token oder Azure AD im Vergleich

Von Mirko Peters · 2026-08-11

Welcome back to the blog! If you have ever stared at a product roadmap, trying to decide whether to embed custom communication features directly into your web app or ... Once you paste the full text, I'll return it in the required marker format.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Titelbild: Identity Islands: Navigating ACS Tokens vs Azure AD

Willkommen zurück im Blog! Wenn Sie schon einmal über einer Produkt-Roadmap saßen und überlegt haben, ob Sie individuelle Kommunikationsfunktionen direkt in Ihre Web-App einbetten oder Ihre Benutzer in die Unternehmenswelt von Microsoft Teams zwingen sollen, sind Sie nicht allein. Die falsche Kommunikationsarchitektur kann zu erheblichen technischen Schulden, unerwarteten Lizenzkosten und Hürden beim Onboarding führen, die die Akzeptanz komplett ausbremsen. Damit Sie sich in diesem Umfeld zurechtfinden, betrachten wir die grundlegenden Unterschiede zwischen der Verwaltung app-ausgestellter Token in Azure Communication Services (ACS) und der Authentifizierung von Mitarbeitenden über Azure AD. Außerdem zeigen wir, wie Sie diese beiden getrennten Identitätssysteme beim Aufbau von Kommunikationsarchitekturen aufeinander abbilden.

Dieser Deep Dive ergänzt unsere aktuelle Podcast-Folge direkt. Wenn Sie eine ausführliche Audio-Aufbereitung dieser praxisnahen Abwägungen hören möchten, sehen Sie sich unbedingt Azure Communication Services vs Teams APIs an.

Für wen dieser Beitrag gedacht ist

Produktverantwortliche, die Kundenchat oder Anruffunktionen in Web- oder Mobile-Apps ausliefern
Plattformarchitekten, die Microsoft 365, Azure AD und Graph zusammenbringen
Engineering-Manager, die keine bösen Überraschungen bei Compliance oder Lizenzierung erleben möchten

Das Wichtigste in Kürze

Die Identität bestimmt alles. ACS ist für externe oder anonyme Benutzer flexibel einsetzbar. Teams-APIs sind für interne Benutzer an Azure AD gebunden, erschweren aber das Onboarding von Gästen.
Präsenz trennt die Welten. Teams-APIs stellen über Graph umfangreiche Präsenzinformationen bereit. ACS bietet keine native Teams-Präsenz. Rechnen Sie mit eigener Synchronisierung oder Kompromissen.
Chat-Funktionsumfang ist entscheidend. Teams bildet die Clientfunktionen ab (Threads, Reaktionen, Karten). ACS ist schlank und einbettbar, die fehlende Benutzeroberfläche müssen Sie aber selbst entwickeln.
Für Anrufe gibt es Grenzen. Die Interoperabilität zwischen ACS und Teams-Besprechungen ist nicht nativ verfügbar. Gäste, die über Teams beitreten, benötigen häufig Einladungen als Azure-AD-Gäste.
Compliance gegen Kosten. Teams übernimmt die Compliance von Microsoft 365 (eDiscovery, DLP, Rechtliche Aufbewahrung), ist aber an E3/E5 sowie Premium-Funktionen und Drosselung gebunden. ACS wird nutzungsabhängig abgerechnet, dafür verantworten Sie Speicher, Aufbewahrung und Audits selbst.
Hybrid ist leistungsstark, im Betrieb aber aufwendig. Rechnen Sie mit Middleware für die Identitätszuordnung, die Nachrichtentransformation, die Präsenzsynchronisierung und die Durchsetzung von Richtlinien.

Kurzempfehlung: ACS, Teams oder Hybrid?

Wählen Sie ACS, wenn Sie reibungslos B2C-Skalierung, anonymen oder Gastchat, schnelle Mobile- und Web-SDKs sowie eine detaillierte Kostenkontrolle benötigen, und Sie bereit sind, Token-Lebenszyklen, Speicher, Aufbewahrung und Audits selbst zu verantworten.
Wählen Sie Teams-APIs, wenn Ihre Kernbenutzer Mitarbeitende sind, die Präsenz, Threads, Besprechungsbeitritte und integrierte Compliance unter Mandantenrichtlinien benötigen. Dafür nehmen Sie den Aufwand für Lizenzierung und Graph-Berechtigungen in Kauf.
Setzen Sie auf Hybrid, wenn Sie externe Unterhaltungen für interne Agenten in Teams sichtbar machen müssen oder öffentlichen Chat bzw. öffentliche Anrufe mit der Compliance und Präsenz von Teams kombinieren möchten.

Typische Stolperfallen aus der Praxis

Zwei Identitätsinseln: ACS-Token und Azure-AD-Objekte erfordern eine Zuordnungsschicht.
Belastung durch Gastzugänge: AAD-Gästeeinladungen bremsen schnelle B2C-Prozesse aus.
Präsenzdifferenz: ACS kann nicht erkennen, dass ein Mitarbeiter gerade in einer Teams-Besprechung beschäftigt ist.
Umgang mit Anhängen: Teams setzt auf OneDrive und SharePoint, ACS arbeitet häufig mit Blobs und URLs.
Versteckte Grenzwerte: Graph-Drosselung und Premium-Endpunkte können bei hoher Last zum Problem werden.
Mehraufwand für Compliance bei ACS: Sie verantworten Verschlüsselung, Aufbewahrung, Audit-Protokolle und Zusicherungen zur Datenregion.

Funktionsvergleich im Detail

Identität und Zugriff

ACS: App-ausgestellte Benutzer und Token eignen sich gut für Websitebesucher und externe Dienstleister. MFA, Widerruf und Ablauf verantworten Sie selbst.
Teams-APIs: Single Sign-on über Azure AD für Mitarbeitende. Gäste benötigen Einladungen und Zustimmung und müssen zu den Mandantenrichtlinien passen.

Präsenz

Teams-APIs: Umfassende Präsenz in Echtzeit über Graph für den gesamten Mandanten.
ACS: Keine native Teams-Präsenz. Dafür sind eigene Telemetrie und Synchronisierung erforderlich.

Chat und Benutzeroberfläche

Teams-APIs: Threads, Reaktionen, Karten, Antworten und Dateien direkt im Chat. Der Funktionsumfang entspricht weitgehend Teams.
ACS: Schlanke Nachrichtenfunktionen. Threads, Suche, benutzerdefinierte Emojis und Persistenz müssen Sie selbst ergänzen.

Anrufe/Besprechungen

ACS: Sprache und Video in Ihre App einbetten; ideal für öffentlichen Zugriff; Medienpfade müssen Sie selbst per Fehlersuche prüfen.
Teams-APIs: Nahtlos für Mandantenbenutzer; die externe Teilnahme erfordert meist das Onboarding als AAD-Gast.

SDK & DevEx

ACS: Einheitliche SDKs für Web, iOS und Android; schnell eingebunden.
Teams/Graph/Bot: Leistungsstark, aber mit steilerer Lernkurve (Berechtigungen, Webhooks, Paging).

Compliance & Lizenzierung

Teams: eDiscovery, DLP, Rechtssperre und Datenresidenz sind integriert; Bezahlung über M365-Lizenzen und ggf. Premium-Funktionen bzw. Limits.
ACS: Abrechnung nach Nutzung; Sie bestimmen Speicherort, Aufbewahrung, SIEM und Audit-Exporte selbst.

Referenzarchitekturen (Denkmodelle)

B2C-Portal (ACS-first): ACS-Chat/Anrufe -> Ihr Speicher/Ihre Aufbewahrung -> optionale Weiterleitung in Teams über Bot/Kanal für Support-Mitarbeitende.
Interner Helpdesk (Teams-first): Teams-Chat/Bot + Graph-Presence -> SSO für Mitarbeitende -> optionale öffentliche Annahme über Formulare oder Gastonboarding.
Hybrid-Brücke: ACS für das öffentliche Widget <-> Middleware (ID-Zuordnung, Nachrichtentransformation, Presence-Synchronisierung, Compliance-Hooks) <-> Teams-Kanal und Agent-Erlebnis.

Checkliste für den Aufbau

Definieren Sie den primären Benutzer: Mitarbeitende, externe Dienstleister oder die Öffentlichkeit.
Entscheiden Sie, wo die Daten liegen und wer für Aufbewahrung und Audits verantwortlich ist.
Erfassen Sie die Identitätsabläufe (SSO, Gäste, anonyme Zugriffe), bevor Sie Code schreiben.
Prüfen Sie die Presence-Anforderungen früh – nicht erst später nachrüsten.
Führen Sie Lasttests für Graph-Limits sowie den Nachrichten- und Anrufdurchsatz von ACS durch.
Planen Sie das Budget für Lizenzen versus Betrieb ein (Middleware, Audits, Monitoring).
Planen Sie einen Rollback- bzw. Ausstiegspfad, falls sich Ihre Anforderungen im nächsten Quartal ändern.

Häufige Fragen (Kurzfassung)

Können ACS-Benutzer nativ an einer Teams-Besprechung teilnehmen? Nicht direkt; rechnen Sie mit einer Brücke oder einem AAD-Gastverfahren.
Benötigen ACS-Benutzer M365-Lizenzen? Nein, ACS wird nutzungsbasiert abgerechnet.
Unterstützen Teams-APIs externe anonyme Benutzer? Nicht sauber; in der Regel ist ein AAD-Gastonboarding erforderlich.
Ist Presence mit ACS verfügbar? Nicht für Teams-Benutzer; dafür sind eine eigene Synchronisierung oder Workarounds nötig.

Nächste Schritte

Ermitteln Sie Ihre drei wichtigsten Must-haves (z. B. anonymer Chat, Teams-Presence, eDiscovery).
Führen Sie einen Spike mit zwei Strängen durch: ein ACS-PoC für öffentlichen Chat und ein Teams-PoC für interne Support-Mitarbeitende.
Wenn beides erforderlich ist, planen Sie ein Middleware-MVP mit ID-Zuordnung, Nachrichtenweiterleitung, minimaler Presence-Synchronisierung und Audit-Protokollierung.
Stimmen Sie das Budget ab: M365-Lizenzen gegenüber ACS-Nutzung plus Personal für Betrieb und Compliance.

Zum Abschluss: Eine Architektur, die Identitätsinseln zwischen Azure Communication Services und Azure AD erfolgreich überbrückt, setzt ein klares Verständnis Ihrer Zielgruppe voraus. Ob Sie ein offenes Consumer-Portal oder einen internen Unternehmens-Helpdesk aufbauen: Wenn Sie die Identität von Anfang an in den Mittelpunkt stellen, ersparen Sie sich später viele Probleme. Für eine vertiefte Diskussion dieser Entscheidungen hören Sie sich unbedingt die begleitende Episode an unter Azure Communication Services vs Teams APIs und abonnieren Sie den Podcast, um bei allen Themen rund um Microsoft 365 und Azure-Architektur immer einen Schritt voraus zu sein!