Wyspy tożsamości: tokeny ACS a Azure AD

By Mirko Peters · 2026-08-11

Witamy ponownie na blogu! Jeśli kiedykolwiek przyglądasz się planowi rozwoju produktu i zastanawiasz się, czy wbudować własne funkcje komunikacji bezpośrednio w swoją aplikację internetową o…

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

Titelbild: Identity Islands: Navigating ACS Tokens vs Azure AD

Witamy ponownie na blogu! Jeśli kiedykolwiek wpatrywałeś się w mapę drogową produktu i zastanawiałeś się, czy osadzić niestandardowe funkcje komunikacji bezpośrednio w swojej aplikacji internetowej, czy też zmusić użytkowników do korzystania z korporacyjnego ogrodu Microsoft Teams, nie jesteś sam. Wybór niewłaściwej architektury komunikacji może prowadzić do ogromnego długu technicznego, niespodziewanych rachunków za licencje i tarć podczas wdrażania użytkowników, które całkowicie hamują adopcję. Aby pomóc Ci uporządkować ten krajobraz, zagłębiamy się w podstawowe różnice między zarządzaniem tokenami wydawanymi przez aplikację w Azure Communication Services (ACS) a poleganiem na Azure AD w uwierzytelnianiu pracowników, a także w tym, jak mapować te dwa odrębne systemy tożsamości podczas budowania architektur komunikacyjnych.

Ten szczegółowy materiał bezpośrednio rozwija nasz najnowszy odcinek podcastu. Jeśli chcesz zapoznać się z kompleksowym audio omówieniem tych praktycznych kompromisów, koniecznie sprawdź Azure Communication Services vs Teams APIs.

Dla kogo jest ten artykuł

Liderzy produktu wdrażający czat i połączenia dla klientów w aplikacjach internetowych lub mobilnych
Architekci platformy pracujący z Microsoft 365, Azure AD i Graph
Menedżerowie inżynierii, którzy nie chcą niespodziewanych pożarów związanych ze zgodnością lub licencjonowaniem

Najważniejsze wnioski

Tożsamość determinuje wszystko. ACS jest elastyczne dla zewnętrznych lub anonimowych użytkowników; interfejsy API Teams są zgodne z Azure AD dla użytkowników wewnętrznych, ale wiążą się z tarciem przy wdrażaniu gości.
Obecność jest punktem podziału. Interfejsy API Teams udostępniają bogatą obecność przez Graph; ACS nie ma natywnej obecności w Teams—spodziewaj się niestandardowej synchronizacji lub kompromisów.
Parytet czatu ma znaczenie. Teams odzwierciedla funkcje klienta (wątki, reakcje, karty); ACS jest lekkie i nadaje się do osadzenia, ale brakujący interfejs użytkownika będziesz musiał zbudować samodzielnie.
Istnieją granice połączeń. Interoperacyjność ACS <-> spotkania Teams nie jest natywna; dołączenie gości przez Teams często wymaga zaproszeń gości w Azure AD.
Zgodność kontra koszt. Teams dziedziczy zgodność Microsoft 365 (eDiscovery, DLP, zablokowanie prawne), ale wiąże się z licencjami E3/E5 i premium oraz realiami ograniczania przepustowości; ACS działa w modelu pay-as-you-go, ale to Ty odpowiadasz za przechowywanie, retencję i audyty.
Model hybrydowy jest potężny—i kosztowny operacyjnie. Spodziewaj się middleware do mapowania tożsamości, transformacji wiadomości, synchronizacji obecności i egzekwowania zasad.

Szybkie wskazówki: ACS, Teams czy model hybrydowy?

Wybierz ACS, jeśli potrzebujesz bezproblemowej skali B2C, czatu anonimowych/gości, szybkości zestawów SDK mobilnych i webowych oraz precyzyjnej kontroli kosztów—i jesteś gotów odpowiadać za cykl życia tokenów, przechowywanie, retencję i audyty.
Wybierz interfejsy API Teams, jeśli Twoimi głównymi użytkownikami są pracownicy, którzy potrzebują obecności, czatu wątkowego, dołączania do spotkań i wbudowanej zgodności w ramach zasad dzierżawy—akceptując związane z tym obciążenie licencyjne i uprawnieniami Graph.
Wybierz model hybrydowy, gdy musisz udostępniać rozmowy zewnętrzne wewnętrznym agentom w Teams lub łączyć publiczny czat/połączenia ze zgodnością i obecnością Teams.

Pułapki z praktyki (z pierwszej ręki)

Dwie wyspy tożsamości: tokeny ACS a obiekty Azure AD -> wymagana warstwa mapowania.
Podatek za doświadczenie gościa: zaproszenia gości AAD spowalniają szybkie procesy B2C.
Niezgodność obecności: ACS nie „widzi”, że konsultant jest zajęty na spotkaniu w Teams.
Obsługa załączników: Teams oczekuje OneDrive/SharePoint; ACS często używa blobów/adresów URL.
Ukryte limity: ograniczanie przepustowości Graph i punkty końcowe premium mogą dać się we znaki przy skali.
Większe obciążenie zgodnością w ACS: Ty odpowiadasz za szyfrowanie, retencję, ślady audytu i gwarancje regionu.

Szczegółowe zestawienie funkcji

Tożsamość i dostęp

ACS: Użytkownicy/tokeny wydawane przez aplikację, świetne dla odwiedzających stronę i podwykonawców; wy odpowiadacie za MFA, unieważnianie i wygasanie.
Interfejsy API Teams: SSO Azure AD dla pracowników; goście wymagają zaproszeń/zgody i zgodności z zasadami dzierżawy.

Obecność

Interfejsy API Teams: Bogata, natychmiastowa obecność przez Graph w całej dzierżawie.
ACS: Brak natywnej obecności Teams; wymaga niestandardowej telemetrii i synchronizacji.

Czat i UX

Interfejsy API Teams: Wątki, reakcje, karty, odpowiedzi, pliki wstawiane w treści—pełen parytet z Teams.
ACS: Lekkie przesyłanie wiadomości; wątki, wyszukiwanie, niestandardowe emotikony i trwałość dodajesz samodzielnie.

Połączenia/spotkania

ACS: osadzasz głos i wideo w swojej aplikacji; świetnie nadaje się do dostępu publicznego; ścieżki multimediów musisz diagnozować samodzielnie.
Teams APIs: bezproblemowe dla użytkowników dzierżawy; dołączenie zewnętrzne zwykle oznacza wdrożenie gości w AAD.

SDK i doświadczenie deweloperskie

ACS: ujednolicone zestawy SDK dla sieci Web, iOS i Androida; szybkie osadzanie.
Teams/Graph/Bot: potężne, ale z bardziej stromą krzywą uczenia się (uprawnienia, webhooki, stronicowanie).

Zgodność i licencjonowanie

Teams: wykrywanie elektroniczne, DLP, blokada prawna i rezydencja danych są wbudowane; płacisz licencjami M365 oraz ewentualnymi funkcjami premium i limitami.
ACS: rozliczanie za zużycie; sam zarządzasz lokalizacją przechowywania, retencją, SIEM i eksportami audytu.

Architektury referencyjne (modele mentalne)

Portal B2C (najpierw ACS): czaty i połączenia ACS -> Twoje przechowywanie i retencja -> opcjonalne przekazywanie do Teams przez bota/kanał dla agentów.
Wewnętrzny helpdesk (najpierw Teams): czat Teams/bot + obecność Graph -> logowanie SSO dla pracowników -> opcjonalne publiczne zgłoszenia przez formularze lub wdrożenie gości.
Mostek hybrydowy: ACS dla publicznego widżetu <-> warstwa pośrednia (mapowanie ID, transformacja wiadomości, synchronizacja obecności, punkty zaczepienia zgodności) <-> kanał Teams/doświadczenie agenta.

Lista kontrolna wdrożenia

Określ głównego użytkownika: pracowników, podwykonawców czy osoby publiczne.
Zdecyduj, gdzie znajdują się dane i kto odpowiada za retencję i audyty.
Zmapuj przepływy tożsamości (SSO, goście, anonimowi użytkownicy) przed napisaniem kodu.
Wcześnie zweryfikuj wymagania dotyczące obecności — nie dokładaj tego na końcu.
Przeprowadź testy obciążeniowe limitów Graph oraz przepustowości wiadomości i połączeń ACS.
Zaplanuj budżet na licencje kontra operacje (warstwa pośrednia, audyty, monitorowanie).
Zaplanuj wycofanie/wyjście, jeśli Twoje potrzeby zmienią się w przyszłym kwartale.

Mini FAQ

Czy użytkownicy ACS mogą natywnie dołączyć do spotkania Teams? Nie bezpośrednio; spodziewaj się mostka lub przepływu gościa w AAD.
Czy potrzebuję licencji M365 dla użytkowników ACS? Nie — ACS rozlicza się za zużycie.
Czy Teams APIs obsługują anonimowych użytkowników zewnętrznych? Nie w sposób czysty; zwykle wymagane jest wdrożenie gości w AAD.
Czy obecność jest dostępna w ACS? Nie dla użytkowników Teams — wymaga niestandardowej synchronizacji lub obejść.

Kroki do podjęcia

Określ swoje 3 najważniejsze wymagania: (np. anonimowy czat, obecność w Teams, wykrywanie elektroniczne).
Przeprowadź dwutorowy spike: PoC ACS dla publicznego czatu; PoC Teams dla wewnętrznych agentów.
Jeśli wymagane są oba, zaplanuj MVP warstwy pośredniej: mapowanie tożsamości, przekazywanie wiadomości, minimalną synchronizację obecności i rejestrowanie audytu.
Uzgodnij budżet: miejsca M365 kontra zużycie ACS + zasoby operacyjne do zgodności.

Podsumowując, projektowanie architektury, która skutecznie łączy wyspy tożsamości między Azure Communication Services a Azure AD, wymaga jasnego zrozumienia swojej grupy odbiorców. Niezależnie od tego, czy budujesz otwarty portal konsumencki, czy wewnętrzny helpdesk przedsiębiorstwa, utrzymanie tożsamości na pierwszym planie oszczędzi Ci wielu problemów w przyszłości. Aby poznać głębszą dyskusję na ten temat, koniecznie posłuchaj odcinka towarzyszącego pod adresem Azure Communication Services vs Teams APIs i zasubskrybuj, aby być na bieżąco ze wszystkim, co dotyczy architektury Microsoft 365 i Azure!