Identity Islands: ACS-tokens versus Azure AD

By Mirko Peters · 2026-08-11

Welkom terug op de blog! Als je ooit naar een productroadmap hebt zitten staren en hebt geprobeerd te beslissen of je aangepaste communicatiefuncties rechtstreeks in je webapp wilt inbouwen…

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

Titelbild: Identity Islands: Navigating ACS Tokens vs Azure AD

Welkom terug op de blog! Als je ooit naar een productroadmap hebt zitten staren en hebt geprobeerd te beslissen of je aangepaste communicatiefuncties rechtstreeks in je webapp wilt inbouwen, of je gebruikers juist wilt dwingen tot de bedrijfsomgeving van Microsoft Teams, dan ben je niet de enige. De verkeerde communicatiearchitectuur kiezen kan leiden tot enorme technische schuld, onverwachte licentiekosten en wrijving bij het onboarden van gebruikers, waardoor de adoptie volledig stokt. Om je wegwijs te maken in dit landschap duiken we diep in de fundamentele verschillen tussen het beheren van app-uitgegeven tokens in Azure Communication Services (ACS) en het vertrouwen op Azure AD voor medewerkersauthenticatie, en ook in hoe je deze twee afzonderlijke identiteitssystemen op elkaar aansluit wanneer je communicatiearchitecturen bouwt.

Deze diepgaande analyse vormt een rechtstreekse uitbreiding van onze recentste podcastaflevering. Wil je een uitgebreide audiotoelichting op deze praktijkafwegingen, bekijk dan zeker Azure Communication Services vs Teams APIs.

Voor wie dit is

Productleiders die klant-chat en -bellen in web- of mobiele apps uitrollen
Platformarchitecten die navigeren door Microsoft 365, Azure AD en Graph
Engineering managers die geen verrassende compliance- of licentiebranden willen

Belangrijkste punten

Identiteit bepaalt alles. ACS is flexibel voor externe of anonieme gebruikers; Teams-API's sluiten voor interne gebruikers aan op Azure AD, maar voegen wrijving toe bij het onboarden van gasten.
Aanwezigheid is een scheidslijn. Teams-API's tonen rijke aanwezigheid via Graph; ACS heeft geen native Teams-aanwezigheid. Reken op maatwerksynchronisatie of compromissen.
Chatpariteit is belangrijk. Teams spiegelt clientfuncties (threads, reacties, kaarten); ACS is licht en inbedbaar, maar de ontbrekende UX bouw je zelf.
Er zijn grenzen aan bellen. ACS <-> Teams-vergaderinteroperabiliteit is niet native; gastdeelname via Teams vereist vaak uitnodigingen voor Azure AD-gasten.
Compliance versus kosten. Teams erft de M365-compliance (eDiscovery, DLP, juridische bewaring), maar draait op E3/E5 plus premium en throttlingrealiteiten. ACS werkt op basis van betalen naar gebruik, maar jij beheert opslag, bewaring en audits.
Hybride is krachtig, maar duur in beheer. Reken op middleware voor identiteitsmapping, berichttransformatie, aanwezigheidssynchronisatie en handhaving van beleid.

Snelle richtlijn: ACS, Teams of hybride kiezen?

Kies ACS als je soepele B2C-schaal, anonieme of gastchat, snelheid met mobiele en Web-SDK's en fijnmazige kostenbeheersing nodig hebt, en je bereid bent tokenlevenscycli, opslag, bewaring en audits zelf te beheren.
Kies Teams-API's als je kernpubliek uit medewerkers bestaat die aanwezigheid, threaded chat, vergaderdeelname en ingebouwde compliance onder tenantbeleid nodig hebben, met de licentie- en Graph-machtigingsoverhead die daarbij hoort.
Kies voor hybride wanneer je externe gesprekken aan interne agents in Teams moet tonen, of wanneer je publieke chat of gesprekken wilt combineren met Teams-compliance en -aanwezigheid.

Praktijkvalkuilen (uit de praktijk)

Twee identiteitseilanden: ACS-tokens versus Azure AD-objecten -> een mappinglaag is vereist.
Gastervaringsbelasting: AAD-gastuitnodigingen vertragen snelle B2C-flows.
Aanwezigheidsmismatch: ACS kan niet ‘zien’ dat een medewerker bezig is in een Teams-vergadering.
Bijlagenverwerking: Teams verwacht OneDrive/SharePoint; ACS gebruikt vaak blobs/URL's.
Verborgen limieten: Graph-throttling en premium-eindpunten kunnen op schaal pijn doen.
Compliancelast bij ACS: Jij beheert encryptie, bewaring, audittrails en regiogaranties.

Functie-voor-functie-overzicht

Identiteit & toegang

ACS: door de app uitgegeven gebruikers en tokens, goed voor websitebezoekers en externe contractors; jij beheert MFA, intrekking en vervaldatum.
Teams-API's: Azure AD-SSO voor medewerkers; gasten vereisen uitnodigingen, toestemming en afstemming op tenantbeleid.

Aanwezigheid

Teams-API's: rijke, directe aanwezigheid via Graph binnen de hele tenant.
ACS: geen native Teams-aanwezigheid; vereist maatwerktelemetrie en -synchronisatie.

Chat & UX

Teams-API's: threads, reacties, kaarten, antwoorden en bestanden inline, Teams-achtige pariteit.
ACS: lichte berichtenuitwisseling; threads, zoeken, aangepaste emoji's en persistentie voeg je zelf toe.

Oproepen/vergaderingen

ACS: Voeg spraak en video toe aan je app; ideaal voor publieke toegang; problemen met mediapaden los je zelf op.
Teams-API's: Naadloos voor tenantgebruikers; externe deelname betekent vaak het onboarden van AAD-gasten.

SDK & DevEx

ACS: Uniforme SDK's voor web, iOS en Android; snel in te bouwen.
Teams/Graph/Bot: Krachtig, maar met een steilere leercurve (machtigingen, webhooks, paginering).

Compliance & licenties

Teams: eDiscovery, DLP, juridische blokkering en gegevensresidentie zijn standaard ingebouwd; betaling via M365-licenties en mogelijke premium-functies of limieten.
ACS: Facturatie op basis van gebruik; jij bepaalt de opslaglocatie, bewaring, SIEM en auditexports.

Referentiearchitecturen (mentale modellen)

B2C-portaal (ACS-first): ACS-chat/-oproepen -> jouw opslag/bewaring -> optioneel doorsturen naar Teams via bot/kanaal voor medewerkers.
Interne helpdesk (Teams-first): Teams-chat/bot + Graph-aanwezigheid -> SSO voor medewerkers -> optionele publieke intake via formulieren of gastonboarding.
Hybride brug: ACS voor publieke widget <-> middleware (ID-mapping, berichttransformatie, synchronisatie van aanwezigheid, compliancekoppelingen) <-> ervaring via Teams-kanaal/agent.

Bouwchecklist

Bepaal de primaire gebruiker: medewerkers, contractors of publiek.
Bepaal waar de gegevens staan en wie de eigenaar is van bewaring en audits.
Breng de identiteitsstromen in kaart (SSO, gasten, anoniem) voordat je code schrijft.
Valideer de aanwezigheidsvereisten vroeg; plak het er niet later achteraan.
Test de Graph-limieten en de doorvoer van ACS-berichten en -oproepen onder belasting.
Begroot licenties versus beheer (middleware, audits, monitoring).
Plan een terugvalscenario/exit voor als je behoeften volgend kwartaal veranderen.

Korte veelgestelde vragen

Kunnen ACS-gebruikers native deelnemen aan een Teams-vergadering? Niet rechtstreeks; reken op een brug of een AAD-gastflow.
Heb ik M365-licenties nodig voor ACS-gebruikers? Nee, ACS wordt op basis van gebruik gefactureerd.
Kunnen Teams-API's externe anonieme gebruikers aan? Niet netjes; meestal is AAD-gastonboarding nodig.
Is aanwezigheid beschikbaar met ACS? Niet voor Teams-gebruikers; hiervoor is een eigen synchronisatie of workaround nodig.

Actiepunten

Bepaal je top 3 must-haves, bijvoorbeeld: anonieme chat, Teams-aanwezigheid, eDiscovery.
Voer een spike met twee sporen uit: een ACS-PoC voor publieke chat en een Teams-PoC voor interne medewerkers.
Als beide nodig zijn, scope dan een middleware-MVP: identiteitsmapping, berichtenrelay, minimale synchronisatie van aanwezigheid en auditlogging.
Stem het budget af: M365-seats versus ACS-gebruik plus de bezetting voor beheer en compliance.

Tot slot: een architectuur ontwerpen die identiteitseilanden tussen Azure Communication Services en Azure AD succesvol overbrugt, vraagt om een helder beeld van je doelgroep. Of je nu een open consumentenportaal bouwt of een interne helpdesk voor de onderneming, als je identiteit vooraan zet, bespaar je later heel wat hoofdpijn. Voor een diepere discussie over deze keuzes luister je naar de bijbehorende aflevering op Azure Communication Services vs Teams APIs, en abonneer je om op de hoogte te blijven van alles rond Microsoft 365- en Azure-architectuur!