Identity Islands: Menavigasi Token ACS vs 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

Selamat datang kembali di blog! Jika Anda pernah termenung menatap peta jalan produk, bingung memutuskan apakah akan menyematkan fitur komunikasi kustom langsung ke aplikasi web atau memaksa pengguna masuk ke ekosistem perusahaan Microsoft Teams, Anda tidak sendirian. Memilih arsitektur komunikasi yang keliru bisa berujung pada utang teknis yang besar, tagihan lisensi yang tak terduga, dan hambatan onboarding pengguna yang sepenuhnya menghambat adopsi. Untuk membantu Anda memahami lanskap ini, kita akan menyelami perbedaan mendasar antara mengelola token yang diterbitkan aplikasi di Azure Communication Services (ACS) dan mengandalkan Azure AD untuk autentikasi karyawan, serta cara memetakan kedua sistem identitas terpisah ini saat membangun arsitektur komunikasi.

Pembahasan mendalam ini secara langsung memperluas episode podcast terbaru kami. Jika Anda ingin uraian audio menyeluruh tentang trade-off dunia nyata ini, pastikan untuk menyimak Azure Communication Services vs Teams APIs.

Untuk Siapa Artikel Ini

Pemimpin produk yang merilis chat dan panggilan pelanggan ke aplikasi web atau seluler
Arsitek platform yang menavigasi Microsoft 365, Azure AD, dan Graph
Manajer engineering yang tidak ingin menghadapi masalah kepatuhan atau lisensi yang mendadak

Poin Penting

Identitas menentukan segalanya. ACS fleksibel untuk pengguna eksternal/anonim; Teams API selaras dengan Azure AD untuk pengguna internal, tetapi menambah hambatan onboarding tamu.
Presence adalah pemisah. Teams API menyajikan presence yang kaya melalui Graph; ACS tidak memiliki presence Teams bawaan, jadi siapkan sinkronisasi kustom atau kompromi.
Paritas chat itu penting. Teams mencerminkan fitur klien (utas, reaksi, kartu); ACS ringan dan dapat disematkan, tetapi UX yang kurang harus Anda bangun sendiri.
Ada batasan pada panggilan. Interoperabilitas ACS <-> rapat Teams tidak bersifat native; tamu yang bergabung lewat Teams sering memerlukan undangan tamu Azure AD.
Kepatuhan vs biaya. Teams mewarisi kepatuhan Microsoft 365 (eDiscovery, DLP, legal hold) tetapi mengikuti lisensi E3/E5 + premium serta realitas throttling; ACS berbasis bayar sesuai pemakaian, tetapi penyimpanan, retensi, dan audit menjadi tanggung jawab Anda.
Hybrid itu ampuh, tetapi mahal dalam operasional. Siapkan middleware untuk pemetaan identitas, transformasi pesan, sinkronisasi presence, dan penegakan kebijakan.

Panduan Singkat: Pilih ACS, Teams, atau Hybrid?

Pilih ACS jika Anda membutuhkan skala B2C yang mulus, chat anonim/tamu, kecepatan SDK mobile/Web, dan kontrol biaya yang detail, serta Anda siap mengelola siklus hidup token, penyimpanan, retensi, dan audit.
Pilih Teams API jika pengguna inti Anda adalah karyawan yang membutuhkan presence, chat berutas, bergabung ke rapat, dan kepatuhan bawaan di bawah kebijakan penyewa, dengan menerima beban lisensi dan izin Graph.
Pilih Hybrid saat Anda harus menampilkan percakapan eksternal kepada agen internal di Teams atau menggabungkan chat/panggilan publik dengan kepatuhan dan presence Teams.

Jebakan Nyata (Dari Lapangan)

Dua pulau identitas: token ACS vs objek Azure AD memerlukan lapisan pemetaan.
Beban pengalaman tamu: undangan tamu AAD memperlambat alur B2C yang cepat.
Ketidaksesuaian presence: ACS tidak dapat "melihat" bahwa seorang agen sedang sibuk dalam rapat Teams.
Penanganan lampiran: Teams mengharapkan OneDrive/SharePoint; ACS sering menggunakan blob/URL.
Batasan tersembunyi: throttling Graph dan endpoint premium bisa menjadi masalah pada skala besar.
Beban kepatuhan pada ACS: Anda bertanggung jawab atas enkripsi, retensi, jejak audit, dan jaminan wilayah.

Rincian Fitur demi Fitur

Identitas & Akses

ACS: Pengguna/token yang diterbitkan aplikasi, cocok untuk pengunjung situs web dan kontraktor; MFA, pencabutan, dan masa berlaku menjadi tanggung jawab Anda.
Teams API: SSO Azure AD untuk staf; tamu memerlukan undangan, persetujuan, dan keselarasan dengan kebijakan penyewa.

Presence

Teams API: Presence yang kaya dan instan melalui Graph di seluruh penyewa.
ACS: Tidak ada presence Teams bawaan; memerlukan telemetri atau sinkronisasi kustom.

Chat & UX

Teams API: Utas, reaksi, kartu, balasan, dan file inline, dengan paritas setara Teams.
ACS: Perpesanan ringan; utas, pencarian, emoji kustom, dan persistensi harus Anda tambahkan sendiri.

Panggilan/Rapat

ACS: Sematkan suara/video di aplikasi Anda; cocok untuk akses publik; Anda sendiri yang menangani pemecahan masalah jalur media.
Teams APIs: Mulus untuk pengguna dalam penyewa; bergabung dari luar biasanya memerlukan proses onboarding tamu AAD.

SDK & DevEx

ACS: SDK Web/iOS/Android yang terpadu; cepat untuk disematkan.
Teams/Graph/Bot: Kuat, tetapi kurva belajarnya lebih curam (izin, webhook, paging).

Kepatuhan & Lisensi

Teams: eDiscovery, DLP, legal hold, dan residensi data sudah tersedia; pembayaran melalui lisensi M365 serta kemungkinan fitur premium/batasan.
ACS: Penagihan berbasis penggunaan; Anda yang mengatur lokasi penyimpanan, retensi, SIEM, dan ekspor audit.

Arsitektur Referensi (Model Mental)

Portal B2C (ACS-first): Chat/panggilan ACS -> penyimpanan dan retensi Anda sendiri -> relai opsional ke Teams melalui bot/saluran untuk agen.
Helpdesk Internal (Teams-first): Chat/bot Teams + presence Graph -> SSO untuk staf -> intake publik opsional melalui formulir atau onboarding tamu.
Jembatan Hibrida: ACS untuk widget publik <-> middleware (pemetaan ID, transformasi pesan, sinkronisasi presence, kait kepatuhan) <-> saluran Teams/pengalaman agen.

Daftar Periksa Pembangunan

Tentukan pengguna utama: karyawan, kontraktor, atau publik.
Putuskan di mana data disimpan dan siapa yang memiliki retensi/audit.
Petakan alur identitas (SSO, tamu, anonim) sebelum menulis kode.
Validasi kebutuhan presence sejak dini—jangan menambahkannya belakangan.
Lakukan uji beban pada batas Graph serta throughput pesan dan panggilan ACS.
Anggarkan lisensi vs. operasional (middleware, audit, pemantauan).
Rencanakan rollback/keluar jika kebutuhan Anda berubah di kuartal berikutnya.

Pertanyaan Umum Singkat

Dapatkah pengguna ACS bergabung ke rapat Teams secara native? Tidak secara langsung; siapkan jembatan atau alur tamu AAD.
Apakah pengguna ACS memerlukan lisensi M365? Tidak—ACS berbasis penggunaan.
Apakah Teams APIs menangani pengguna eksternal anonim? Tidak secara bersih; biasanya memerlukan onboarding tamu AAD.
Apakah presence tersedia dengan ACS? Tidak untuk pengguna Teams—memerlukan sinkronisasi kustom atau solusi alternatif.

Langkah Tindakan

Identifikasi 3 kebutuhan utama Anda: (misalnya, chat anonim, presence Teams, eDiscovery).
Jalankan spike dua jalur: PoC ACS untuk chat publik; PoC Teams untuk agen internal.
Jika keduanya diperlukan, susun MVP middleware: pemetaan identitas, relai pesan, sinkronisasi presence minimal, dan pencatatan audit.
Selaraskan anggaran: kursi M365 vs penggunaan ACS + jumlah staf operasional untuk kepatuhan.

Sebagai penutup, merancang arsitektur yang berhasil menjembatani pulau identitas antara Azure Communication Services dan Azure AD memerlukan pemahaman yang jelas tentang audiens Anda. Baik Anda membangun portal konsumen terbuka maupun helpdesk perusahaan internal, menjadikan identitas sebagai prioritas utama akan menghemat banyak masalah di kemudian hari. Untuk pembahasan lebih dalam tentang pilihan-pilihan ini, dengarkan episode pendampingnya di Azure Communication Services vs Teams APIs dan berlangganan agar tetap terdepan dalam segala hal tentang Microsoft 365 dan arsitektur Azure!