Zero-Touch OAuth untuk MCP

 (blog.modelcontextprotocol.io)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Ekstensi Enterprise-Managed Authorization (EMA) telah distabilkan, sehingga perusahaan dapat mengelola izin server MCP secara terpusat dan pengguna dapat masuk sekali untuk mengakses server yang diizinkan
  • Pendekatan lama bergantung pada persetujuan OAuth terpisah per pengguna dan per server, sehingga menyulitkan onboarding, penerapan kebijakan keamanan, jejak audit, dan pemisahan akun kerja serta pribadi
  • EMA menempatkan IdP organisasi sebagai pihak penentu otorisasi, sehingga ketika admin mendefinisikan kebijakan satu kali, pengguna mewarisi koneksi MCP yang diperlukan lewat akun organisasi yang sudah ada
  • ID-JAG yang diterbitkan selama SSO ditukar dengan token akses di server otorisasi server MCP, sehingga pengguna tidak dialihkan ke layar persetujuan per server
  • Okta, Anthropic, Visual Studio Code, serta Asana, Atlassian, Canva, Figma, Granola, Linear, dan Supabase termasuk dalam dukungan awal, dan Slack juga sedang menambahkan dukungan

Stabilisasi EMA dan target penerapan perusahaan

  • Ekstensi Enterprise-Managed Authorization (EMA) kini berstatus stable
  • Saat mengelola koneksi server MCP di lingkungan perusahaan, persetujuan berulang dan prompt consent dianggap sebagai ketidaknyamanan besar, dan EMA adalah ekstensi untuk mengurangi masalah ini
  • Organisasi dapat mengendalikan akses ke server MCP secara terpusat melalui Identity Provider (IdP) yang mereka percayai
  • Pengguna akhir masuk dengan akun organisasi yang sudah ada lalu terhubung ke server MCP yang diizinkan, sehingga beban consent OAuth per server atau penyiapan sekali pakai berkurang

Keterbatasan model autentikasi per pengguna

  • Model otorisasi MCP standar dirancang agar sesuai dengan model user-scoped dan praktik autentikasi interaktif tradisional
  • Ini mungkin cocok untuk skenario konsumen di mana individu langsung menentukan target akses ke datanya sendiri, tetapi tidak mudah diskalakan untuk penerapan perusahaan
  • Di lingkungan perusahaan, khususnya ada tiga masalah besar
    • Setiap karyawan harus menyetujui tiap server secara terpisah, sehingga saat onboarding diperlukan koneksi manual per layanan
    • Tim keamanan harus bergantung pada akses yang disetujui tiap pengguna tanpa kontrol terpusat atau jejak audit
    • Sulit memaksa penggunaan akun perusahaan, sehingga pengguna dapat menghubungkan akun pribadi ke alat kerja
  • Friksi semacam ini memperlambat adopsi MCP dan meningkatkan kemungkinan munculnya implementasi bypass yang rapuh
  • Tanpa standar umum untuk mempertahankan status autentikasi bersama, tiap implementator akan membuat solusi terpisah, dan meskipun data serta alat tersedia, sebagian besar bisa tetap nonaktif karena biaya otorisasi per pengguna

Setujui sekali dan warisi di mana saja

  • Enterprise-Managed Authorization menjadikan IdP organisasi sebagai pihak penentu otorisasi untuk akses server MCP
  • Admin mendefinisikan kebijakan satu kali, dan pengguna mengautentikasi diri ke host MCP dengan ID organisasi yang sudah ada
  • IdP dapat mengizinkan atau menolak akses berdasarkan keanggotaan grup, peran, dan aturan akses bersyarat
  • Alur internalnya sebagai berikut
  • Struktur ini memberikan tiga efek
    • Jika admin mengaktifkan server untuk organisasi, pengguna otomatis mendapat akses dalam cakupan grup dan peran yang sudah ada
    • Keputusan akses tercatat di konsol admin IdP, memberikan satu catatan yang dapat diaudit untuk semua konektor
    • Dengan menghapus langkah pemilihan akun interaktif, kebingungan aliran data antara akun pribadi dan akun perusahaan menjadi lebih mudah dikurangi
  • Dalam penggunaan MCP di perusahaan, tujuannya adalah saat pengguna masuk, klien dapat terhubung ke alat dan data yang diizinkan tanpa langkah tambahan

Produk pendukung awal dan ekosistem

  • Pada peluncuran ini, tiga kelompok berpartisipasi dalam implementasi: penyedia identitas, klien, dan server

  • Penyedia identitas

    • Okta adalah penyedia identitas pertama yang mendukung
    • Organisasi yang menggunakan Okta dapat memprovisikan akses MCP ke klien dan server yang didukung melalui Okta’s Cross App Access (XAA)

  • Klien

    • Anthropic mengimplementasikan EMA pada lapisan MCP bersama milik Claude
    • Admin dapat menyetujui server MCP untuk pengguna di seluruh Claude, Claude Code, dan Cowork
    • Visual Studio Code juga menambahkan dukungan EMA di dalam IDE

  • Server

    • Asana, Atlassian, Canva, Figma, Granola, Linear, dan Supabase mendukung EMA
    • Slack dan server lain juga sedang menambahkan dukungan
    • Aaron Parecki dari Okta mengatakan bahwa dengan membangun protokol Cross App Access ke dalam ekstensi EMA milik MCP, identity menjadi bidang tata kelola terpusat, memberikan kontrol kepatuhan kepada tim keamanan dan pengalaman yang mulus bagi pengguna
    • Devdatta Akhawe dari Figma mengatakan bahwa seiring meningkatnya adopsi MCP, XAA memudahkan perusahaan untuk menskalakan penerapan MCP secara aman
    • Tom Moor dari Linear menyinggung pengalaman di mana sekali masuk, semua konektor MCP otomatis disiapkan

Dokumentasi dan kanal partisipasi

  • Klien, server, dan platform identity dapat meninjau spesifikasi ekstensi dan menambahkan dukungan untuk standar baru ini ke produk mereka
  • Halaman Enterprise-Managed Authorization mendokumentasikan persyaratan alur untuk klien, server, dan server otorisasi
  • Perubahan terbaru EMA dan materi dukungan dapat dilihat di repositori ext-auth dan draft specification
  • EMA Interest Group digunakan untuk diskusi ekstensi, laporan kompatibilitas, dan perbaikan berulang
  • EMA adalah hasil kerja komunitas MCP, dengan kontribusi dari penulis SEP-990, pemelihara repositori ext-auth, serta penyedia identity dan MCP yang menguji implementasi awal dan memajukan spesifikasi

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Sebelum masuk ke perdebatan klise “MCP sudah mati dan Skills adalah masa depan”, nilai nyata MCP dibanding skills/CLI adalah bahwa MCP memisahkan alur autentikasi ke luar jendela konteks agen, dan dalam beberapa kasus bahkan ke luar harness.
    Ini jelas penting dari sudut pandang keamanan, dan juga membuat pengalaman pengguna jauh lebih mudah ketika pengguna umum atau perusahaan besar mengadopsi alat AI.
    Saya paham keluhan tentang membengkaknya konteks atau duplikasi pemanggilan alat, tetapi ada nilai yang jelas pada arsitektur yang menangani autentikasi dengan cara ini.
    MCP yang ideal bahkan bisa cukup bermanfaat hanya sebagai gateway autentikasi di depan API.

    • Ekstensi ini juga menunjukkan kelebihan MCP lain dibanding skills: kontrol terpusat, kemudahan penggunaan dari sudut pandang karyawan, audit/kepatuhan, dan model deployment.
      Saat ini, praktik terbaik deployment skills tampaknya sebatas “salin file ini lalu taruh di sini”, “checkout repositori ini lalu tambahkan symbolic link”, atau “instal dengan slash command”.
      Walau sederhana, itu tetap tidak semudah pendekatan ekstensi ini untuk mendistribusikan server MCP baru ke karyawan.
    • MCP juga memungkinkan jejak audit yang sangat baik.
      Misalnya, Anda bisa mengautentikasi 6 akun Linear dari 6 pelanggan, lalu menerapkan pemisahan tanggung jawab dengan memilih akun mana yang digunakan secara deterministik dan dapat diaudit.
    • Pelajaran sebenarnya adalah bahwa MCP versus skills bukanlah dikotomi biner.
      Keduanya hanyalah alat yang berbeda, dan tergantung kebutuhannya, salah satunya bisa lebih baik atau tidak.
      Ini mirip dengan bertanya mana yang lebih baik antara pisau dan gergaji.
    • Selain itu, MCP memungkinkan menghubungkan platform eksternal tanpa lingkungan runtime.
      Setiap kali topik ini muncul, para engineer memperlakukan Claude Code seolah-olah itu satu-satunya aplikasi agen AI, tetapi ada banyak use case di berbagai industri di luar coding.
      Harness bisa saja berjalan bukan di mesin lokal, melainkan di kontainer cloud yang terisolasi dan dibatasi, di mana eksekusi kode arbitrer sama sekali tidak diperbolehkan.
      Namun ketika pelanggan tetap ingin menghubungkan alat yang sudah ada ke agen, MCP sangat cocok karena menyediakan connector dengan autentikasi bawaan, sedangkan skills tidak berada di ranah ini.
    • Saya sedang membuat platform untuk ulasan restoran bersama teman-teman, dan setelah beberapa kali trial and error, MCP tampaknya adalah arah yang tepat.
      Pengguna biasa tidak akan mencari direktori Claude lalu menempelkan file skill.
      “Connections” mudah dipahami, dan menempelkan MCP atau mencarinya di marketplace terasa lebih mudah.
      Masih belum pasti apakah akses agen ke tempat dan ulasan benar-benar akan berguna.

  • Selamat besar kepada orang-orang di Okta, Anthropic, Microsoft, Figma, Linear, dan lainnya yang membuat pekerjaan ini.
    Bahkan bagi para skeptis MCP, ada sesuatu yang berguna di sini.
    Ini bekerja dengan format token baru bernama ID-JAG, yang dijelaskan di https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a....
    Ini sama sekali bukan khusus untuk MCP, dan ID-JAG bisa digunakan di mana pun aplikasi yang memakai penyedia SSO yang sama perlu berbagi data dengan aman.

    • Perusahaan-perusahaan seperti inilah yang membuat perangkat lunak dan kualitas hidup makin buruk, jadi rasanya ini benar-benar sesuatu yang pantas diberi “selamat” dengan nada sinis.

  • Saya sedang mencoba menambahkan autentikasi Microsoft Entra ID ke server MCP yang sedang saya bangun, dan jujur rasanya seperti saya yang bodoh
    Melalui header WWW-Authenticate, kita bisa memberi tahu klien URL metadata resource, dan dari situ juga bisa menentukan Microsoft Entra sebagai server autentikasi serta cakupan pendaftaran aplikasi
    Tapi client_id tidak bisa ditentukan, seolah-olah setiap klien, yaitu agen, harus membuatnya sendiri
    Untuk memulai login ke URL .../authorize milik Microsoft Entra, dibutuhkan client_id yang sudah dikenal dan cocok dengan pendaftaran aplikasi di Entra, tetapi nilai yang dibuat sembarang oleh klien jelas tidak akan cocok dengan Entra
    Secara teori ini bisa didukung dengan pendaftaran klien dinamis, tetapi tentu saja Microsoft Entra tidak mendukungnya
    Pada akhirnya, satu-satunya cara yang terlihat adalah membuat shim pendaftaran klien dinamis sendiri di depan Microsoft Entra dan mengembalikan client_id statis yang sama ke semua pihak
    Rasanya saya mungkin melewatkan sesuatu yang jelas, atau memang beginikah protokol ini bekerja di enterprise tanpa jalan memutar?

    • Sepertinya Anda memang tidak melewatkan hal yang jelas
      Entra ID tidak mendukung pendaftaran klien dinamis, dan kondisi ekosistem ini memang belum bagus
      Biasanya OAuth MCP ditangani dengan klien tradisional yang didaftarkan sebelumnya, tetapi dalam praktiknya banyak klien MCP berasumsi bahwa pendaftaran klien dinamis tersedia dan tidak menyediakan opsi untuk menentukan client_id
      Namun beberapa klien memang mendukungnya, dan sekalian promosi, alat kami Erato juga mendukungnya: https://erato.chat/docs
      Solusi umum yang diterapkan di enterprise juga biasanya memusatkan akses MCP melalui web UI, jadi ini didukung
      Alternatif lain adalah gateway MCP; antara gateway dan layanan bisa memakai OAuth yang didaftarkan sebelumnya, dan antara gateway dan klien bisa mengizinkan pendaftaran klien dinamis
    • Kami juga mengalami masalah yang sama karena client_id, dan dari sisi keamanan kami tidak ingin mengaktifkan pendaftaran klien dinamis
      Akhirnya kami membuat aplikasi memproksikan alur OAuth sambil menyuntikkan client_id yang di-hardcode
      Kepada klien MCP, kami berpura-pura mendukung pendaftaran klien dinamis, tetapi di internal strukturnya tetap memakai client_id terpisah untuk MCP seperti biasa
      Contohnya ada di sini: https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...
    • Saya baru mengimplementasikannya kemarin, dan intinya pustaka ini menjalankan server MCP: https://csharp.sdk.modelcontextprotocol.io/concepts/identity...
      Lalu saya membuat aplikasi broker autentikasi yang menangani pendaftaran klien dengan OpenID dan membuat JWT
      Hasilnya, kini kami bisa menentukan apakah suatu alat dapat digunakan dan izin apa yang dimilikinya berdasarkan divisi karyawan atau kriteria lain
      Pada akhirnya, pendaftaran klien dinamis memang diperlukan
    • Baru-baru ini FusionAuth mendokumentasikan cara menggunakan klien yang didaftarkan sebelumnya: https://fusionauth.io/docs/extend/examples/controlling-acces...
      CIMD, saudara DCR yang lebih baru dan lebih baik, juga sedang kami evaluasi dan dibahas secara aktif, tetapi belum tersedia: https://github.com/FusionAuth/fusionauth-issues/issues/3230
      Sebagai alternatif dari proxy yang Anda usulkan, ada pendekatan membuat client_id Entra baru dengan PKCE aktif untuk setiap klien MCP melalui portal pengembang atau semacamnya, lalu meminta pengguna mengatur nilai itu di klien mereka
      Perintah CLI untuk itu saya temukan di sini, dan sepertinya juga ada API: https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azur...
      Pengaturan Claude Code ada di https://code.claude.com/docs/en/mcp, dan pengaturan ChatGPT ada di https://developers.openai.com/api/docs/guides/developer-mode
      Pendaftaran klien sebelumnya mungkin bukan yang paling ideal bagi developer, tetapi masih bisa diterima, dan di spesifikasi pun ini diperlakukan sebagai pendekatan kelas satu: https://modelcontextprotocol.io/specification/2025-11-25/bas...
      Jika pengguna utamanya adalah karyawan internal dan mereka bisa mengikuti panduan konfigurasi untuk mengakses server MCP, pendekatan ini juga bisa berjalan
      Tetapi jika targetnya adalah integrasi publik yang luas untuk pengguna non-developer, ini jelas tidak cukup bisa diterima, dan justru di situlah kekuatan serta peluang besar MCP berada

  • Saya salah satu orang yang membuat ini di Anthropic bersama Okta dan beberapa mitra MCP
    Sangat antusias melihat bentuk seperti ini mulai terbentuk di Claude, dan sekarang setelah EMA menjadi ekstensi stabil dalam spesifikasi MCP, saya ingin memperluas adopsinya ke penyedia identitas dan klien lain
    Kalau ada masukan, akan bagus jika ditinggalkan di sini; saya selalu ingin mendengar pengalaman penggunaan nyata dan cara untuk memperbaikinya

    • Sudah lama
      Sudah cukup lama saya tidak mengikuti MCP, tetapi ini tampaknya sangat cocok untuk membuat MCP lebih aman di organisasi dan mengatasi kelemahan pendaftaran klien dinamis
      Sekarang klien dan URI pengalihan yang disetujui bisa dikonfigurasi langsung oleh penyedia identitas dan organisasi, jadi serangan berbasis DCR seperti confused deputy attack atau phishing bisa dimitigasi lebih luas
      Selain itu, ini juga jadi keuntungan besar karena mengurangi logika otorisasi yang sebelumnya harus diimplementasikan server MCP ketika penyedia identitas atau organisasi tidak mendukung DCR
      Kekurangannya, untuk penggunaan konsumen tampaknya DCR masih tetap diperlukan
      Mungkin ini bisa diatasi jika penyedia OAuth konsumen seperti GitHub, GitLab, dan Google mendukung pendaftaran statis klien/server MCP, klien menanamkan client_id statis, dan pengguna masuk dengan penyedia identitas tersebut lalu mengelola koneksinya sendiri
      Secara keseluruhan, XAA/EMA tampak jauh lebih unggul daripada DCR dalam hal keamanan dan kemudahan penggunaan
      Bagian yang mengkhawatirkan juga jauh lebih mudah diselesaikan dibanding DCR dan dampak keamanannya lebih kecil, karena penyerang tidak bisa mendaftarkan kliennya sendiri dan pengembang server MCP juga lebih sedikit terjebak jebakan
    • Sangat bagus untuk “aplikasi” biasa, tetapi bagi kami yang sangat dibutuhkan adalah cara berinteraksi model agen dengan hambatan lebih rendah tanpa pengguna harus menyiapkan MCP
      Akan bagus jika ada semacam sesi sementara atau penyimpanan token di luar jalur
      Kasus penggunaannya adalah dalam proses penjualan, pembeli dan penjual perlu bertukar banyak informasi dan menganalisisnya, dan analisis ini semakin bersifat agen
      Masalah MCP adalah hambatan penyiapan awalnya jauh lebih besar dibanding pengguna langsung masuk dan mengambil informasi yang diperlukan
      MCP bagus untuk interaksi yang rutin dan sering, tetapi bermasalah untuk sesi cepat sekali pakai
      Akan bagus jika di Claude bisa mengatakan “ambil dokumen dari X, Y, Z”, lalu Claude mengakses situs tersebut, dan situs mengembalikan info penggunaan dasar serta tautan login yang bisa dibuka pengguna di browser
      Pengguna mengautentikasi di browser, lalu callback mengembalikan token sekali pakai yang unik dan berumur pendek, yang kemudian ditukar dalam permintaan situs berikutnya
      Dengan begitu pengguna bisa diautentikasi dengan cepat sambil tetap mempertahankan status sesi selama pekerjaan berlangsung
    • Saya penasaran apakah ada komunikasi dengan tim Microsoft Entra, yaitu Azure AD
      Saya ingin tahu apakah ini sesuatu yang bisa diharapkan segera, atau akan memakan waktu cukup lama
    • Selamat atas peluncurannya
      Kasus penggunaan utamanya tampaknya adalah karyawan perusahaan, tetapi saya penasaran apakah ada nilai serupa juga untuk pengguna yang tidak tersentralisasi seperti pelanggan atau pengguna freemium
      Saya belum bisa membayangkannya, jadi saya ingin tahu apakah ada sesuatu yang saya lewatkan, dan saya rasa saya melihat jawaban terkait di sini: https://news.ycombinator.com/item?id=48594381
    • Saya hanya ingin memastikan bahwa ini belum benar-benar bisa digunakan dan masih pada tahap SEP

  • Ini benar-benar luar biasa
    Selama beberapa bulan terakhir saya beruntung bisa bekerja bersama orang-orang MCP pada beberapa SEP dan SDK eksperimental Go
    Dulu saya termasuk orang yang skeptis, yang berkata, “kan cuma API”, “buat abstraksi lagi”
    Yang sering dilewatkan orang adalah huruf “P” dalam MCP membuat kesalahpahaman
    Saat membuat aplikasi tradisional, kita harus membuat form, UI, penanganan request/response, kanal dua arah, pekerjaan yang berjalan lama, autentikasi, dan sebagainya
    Dengan MCP, 80% dari lapisan umum ini sudah ditangani, jadi MCP memang protokol, tetapi pada praktiknya juga lebih dekat ke framework aplikasi
    Autentikasi terintegrasi adalah peningkatan besar, dan saya menantikan hal-hal yang lebih keren ke depannya

  • Cukup aneh melihat pekerjaan yang saya buat terlihat dari luar
    Di Atlassian saya menangani implementasi sisi RAS dari alur ini
    Jelas akan ada perbaikan berulang pada alur ini, seperti CIMD, dukungan tenancy yang lebih baik, dan lainnya
    Semua orang di Anthropic, Okta, dan Atlassian yang mewujudkan ini sangat hebat

  • Akan bagus jika ada dukungan web sehingga kita bisa langsung menerbitkan cookie jangka panjang
    Saya meretas spesifikasi agar cookie bisa diteruskan lewat handshake OAuth untuk melakukan ini tanpa server OAuth
    Sangat membuat frustrasi bahwa hal seperti ini tidak ingin diizinkan
    Jika tidak ada cookie, cukup buka halaman web, lalu setelah cookie disetel, tutup dan simpan
    Saya bahkan menulis minibuku 80 halaman tentang MCP, tetapi tetap saja ini terasa sangat membuat frustrasi

    • Saya salah satu lead maintainer proyek MCP, dan pendekatan ini tidak bisa diskalakan dalam berbagai skenario
      Ada masalah baik dari sisi kegunaan maupun keamanan, dan cookie dibuat untuk browser
      Server dan klien MCP sering berjalan di lingkungan yang tidak menjamin adanya browser
    • Itu pada dasarnya seperti meminta agar kredensial dicuri
      Kredensial jangka panjang membawa beban tanggung jawab yang besar

  • Saya sudah membacanya beberapa kali, dan ini jelas berguna
    Audit dan kontrol akses bisa dipusatkan pada satu penyedia identitas, dan penyedia identitas juga bisa bertindak seperti proxy API gateway yang menangani pertukaran token saat diperlukan
    Ini adalah pendekatan yang juga diadopsi pemain lain di bidang ini
    Secara pribadi saya agak tidak nyaman dengan fakta bahwa penyedia identitas mendelegasikan wewenang saya ke klien tanpa saya sadari
    Mungkin karena saya terlalu terbiasa dengan alur yang menghadirkan pengguna di browser, dan ini terasa seperti evolusi menuju sentralisasi akses untuk mesin
    Di lingkungan enterprise, identitas memang dimiliki perusahaan, bukan individu, jadi ini mungkin bisa diterima
    Tetapi mengintegrasikannya ke sisi customer ID adalah tantangan yang sama sekali berbeda, dan mungkin tidak mudah membangun kepercayaan seperti ini antara penyedia identitas, klien, dan resource authorization server

    • Tidak ada hambatan teoretis yang mencegah integrasi ini bekerja di ranah konsumen
      Misalnya, cukup buat hubungan kepercayaan seperti jika Anda sudah masuk ke GitHub maka Anda juga otomatis masuk ke Sentry
      Masih banyak pekerjaan yang harus dilakukan ke depan, tetapi saat ini kasus penggunaan yang paling jelas memang seperti yang Anda katakan: enterprise

  • Di C1, autentikasi MCP menjadi masalah besar baik untuk penggunaan MCP internal maupun MCP Gateway di dalam produk, jadi sangat senang ini akhirnya hadir
    Hari ini C1 merilis dukungan agar dapat bertindak sebagai penyedia identitas EMA, dan menerbitkan token berumur pendek dengan cakupan terbatas
    Sekarang saya ingin menghubungkannya ke Linear dan MCP lain yang kami gunakan agar lepas dari alur OAuth yang berulang-ulang
    Claude sudah melakukan hal seperti ini secara ajaib pada beberapa konektor bawaan, setidaknya di Slack, dan pengalamannya cukup bagus
    Sebagai pengungkapan, saya adalah VPE di C1, dan kami sudah mendokumentasikan pendekatan ini untuk orang yang ingin mendalaminya: https://www.c1.ai/docs/product/admin/enterprise-managed-auth...

  • Saya kurang paham apa kelebihan ini dibanding OAuth biasa
    Sepertinya perlu contoh perbandingan alur otorisasi

    • Dalam OAuth biasa, pengguna akhir memberikan persetujuan secara terpisah pada tiap aplikasi untuk membagikan datanya
      Ini masuk akal untuk kasus penggunaan konsumen, yaitu ketika pengguna akhir memiliki datanya sendiri
      Tetapi dalam banyak kasus penggunaan bisnis, pihak yang harus membagikan data dan mengendalikan akses bukanlah pengguna akhir, melainkan perusahaan
      Jika saya adalah karyawan Acme, saya seharusnya tidak memutuskan apakah data Google Drive milik Acme dihubungkan ke Claude atau ChatGPT; itu seharusnya diputuskan oleh departemen TI
      Enterprise-Managed OAuth, atau Cross App Access (XAA), membawa model berbagi yang dikendalikan secara terpusat oleh admin TI ke dalam kerangka OAuth agar bisa bekerja bersama ekosistem yang sudah ada
      Selain itu, dengan memindahkan pengelolaan persetujuan berbagi data dari karyawan ke admin TI, ada keuntungan besar dari sisi pengalaman pengguna
      Karyawan tidak perlu melewati banyak alur OAuth untuk menghubungkan akun, karena admin TI sudah lebih dulu menyiapkan kontrol berbagi
      Bayangkan hari pertama masuk kerja dan Slack sudah terhubung ke Zoom, Drive, Calendar, dan lainnya
    • Keuntungannya adalah pengguna tidak perlu mengendalikan atau menyetujui aplikasi mana saja yang diizinkan saling berbagi informasi mereka
      Karena keputusan pendelegasian akses dibuat di tingkat kebijakan penyedia identitas
      Pengguna bahkan mungkin tidak akan pernah tahu aplikasi atau layanan mana yang diizinkan untuk membagikan informasi mereka
      Tunggu, apakah itu benar-benar kelebihan? ;-)