Zero-Touch OAuth cho MCP
(blog.modelcontextprotocol.io)- Tiện ích mở rộng Enterprise-Managed Authorization (EMA) đã đạt trạng thái ổn định, cho phép doanh nghiệp quản lý tập trung quyền của máy chủ MCP và người dùng chỉ cần đăng nhập một lần để truy cập các máy chủ đã được cấp phép
- Cách làm trước đây phụ thuộc vào phê duyệt OAuth riêng lẻ theo từng người dùng và từng máy chủ, khiến việc onboarding, áp dụng chính sách bảo mật, theo dõi kiểm toán và tách biệt tài khoản công việc/cá nhân trở nên khó khăn
- EMA đặt IdP của tổ chức làm chủ thể ra quyết định cấp quyền; quản trị viên chỉ cần định nghĩa chính sách một lần, còn người dùng sẽ kế thừa các kết nối MCP cần thiết bằng tài khoản tổ chức hiện có
- ID-JAG được cấp trong quá trình SSO sẽ được đổi thành access token tại máy chủ ủy quyền của máy chủ MCP, vì vậy người dùng không bị chuyển hướng đến màn hình đồng ý riêng cho từng máy chủ
- Okta, Anthropic, Visual Studio Code cùng Asana, Atlassian, Canva, Figma, Granola, Linear và Supabase nằm trong nhóm hỗ trợ ban đầu; Slack cũng đang bổ sung hỗ trợ
EMA ổn định hóa và mục tiêu triển khai cho doanh nghiệp
- Enterprise-Managed Authorization (EMA) extension đã đạt trạng thái stable
- Khi quản lý kết nối đến máy chủ MCP trong môi trường doanh nghiệp, việc phải phê duyệt lặp lại và xuất hiện liên tục các lời nhắc đồng ý là một bất tiện lớn; EMA là tiện ích mở rộng nhằm giảm vấn đề này
- Tổ chức có thể kiểm soát tập trung việc truy cập máy chủ MCP thông qua nhà cung cấp danh tính (IdP) mà họ tin cậy
- Người dùng cuối đăng nhập bằng tài khoản tổ chức hiện có rồi kết nối đến các máy chủ MCP đã được cấp phép, giảm gánh nặng đồng ý OAuth theo từng máy chủ hoặc các bước thiết lập dùng một lần
Giới hạn của mô hình xác thực theo từng người dùng
- Mô hình cấp quyền MCP tiêu chuẩn được thiết kế xoay quanh phạm vi theo người dùng (user-scoped) và các thông lệ xác thực tương tác truyền thống
- Cách này có thể phù hợp với các kịch bản tiêu dùng, nơi mỗi cá nhân tự quyết định dữ liệu nào mình muốn truy cập, nhưng không mở rộng tốt trong triển khai doanh nghiệp
- Trong môi trường doanh nghiệp, đặc biệt nổi lên ba vấn đề
- Mỗi nhân viên phải tự phê duyệt từng máy chủ, nên quá trình onboarding đòi hỏi kết nối thủ công cho từng dịch vụ
- Đội ngũ bảo mật phải dựa vào các quyền truy cập do từng người dùng tự phê duyệt mà không có kiểm soát tập trung hay dấu vết kiểm toán đầy đủ
- Khó buộc phải dùng tài khoản công ty, khiến người dùng có thể kết nối tài khoản cá nhân với công cụ công việc
- Những ma sát này làm chậm việc áp dụng MCP và làm tăng khả năng xuất hiện các cách triển khai lách luật, kém an toàn
- Nếu không có một tiêu chuẩn phổ quát để bảo toàn trạng thái xác thực dùng chung, mỗi bên triển khai sẽ phải tự tạo giải pháp riêng; ngay cả khi đã có dữ liệu và công cụ, phần lớn vẫn có thể bị để ở trạng thái tắt vì chi phí cấp quyền theo từng người dùng
Phê duyệt một lần và kế thừa ở mọi nơi
- Enterprise-Managed Authorization biến IdP của tổ chức thành chủ thể ra quyết định cấp quyền truy cập máy chủ MCP
- Quản trị viên định nghĩa chính sách một lần, còn người dùng xác thực với máy chủ MCP bằng ID tổ chức hiện có
- IdP có thể cho phép hoặc từ chối truy cập dựa trên tư cách thành viên nhóm, vai trò và các quy tắc truy cập có điều kiện
- Luồng nội bộ diễn ra như sau
- Client lấy Identity Assertion JWT Authorization Grant (ID-JAG) từ IdP trong quá trình SSO
- Client gửi nó tới máy chủ ủy quyền của máy chủ MCP để đổi lấy access token
- Người dùng không phải đi qua màn hình đồng ý riêng cho từng máy chủ
- Cấu trúc này mang lại ba hiệu quả
- Khi quản trị viên kích hoạt máy chủ cho tổ chức, người dùng sẽ tự động có quyền truy cập trong phạm vi nhóm và vai trò hiện có
- Các quyết định truy cập được lưu lại trong bảng điều khiển quản trị của IdP, tạo ra một bản ghi kiểm toán duy nhất cho mọi connector
- Việc loại bỏ bước chọn tài khoản mang tính tương tác giúp giảm nhầm lẫn về luồng dữ liệu giữa tài khoản cá nhân và tài khoản doanh nghiệp
- Mục tiêu trong việc sử dụng MCP cho doanh nghiệp là khi người dùng đăng nhập, client có thể kết nối đến các công cụ và dữ liệu đã được cấp phép mà không cần thêm bước nào
Sản phẩm hỗ trợ ban đầu và hệ sinh thái
- Trong đợt phát hành này, ba nhóm tham gia triển khai là nhà cung cấp danh tính, client và máy chủ
-
Nhà cung cấp danh tính
- Okta là nhà cung cấp danh tính đầu tiên hỗ trợ
- Các tổ chức dùng Okta có thể cấp phát quyền truy cập MCP cho client và máy chủ được hỗ trợ thông qua Okta’s Cross App Access (XAA)
-
Client
- Anthropic đã triển khai EMA trong lớp MCP dùng chung của Claude
- Quản trị viên có thể phê duyệt các máy chủ MCP cho người dùng trên toàn bộ Claude, Claude Code và Cowork
- Visual Studio Code cũng đã bổ sung hỗ trợ EMA trong IDE
-
Máy chủ
- Asana, Atlassian, Canva, Figma, Granola, Linear và Supabase hỗ trợ EMA
- Slack và các máy chủ khác cũng đang bổ sung hỗ trợ
- Aaron Parecki của Okta cho biết việc tích hợp giao thức Cross App Access vào tiện ích mở rộng EMA của MCP biến danh tính thành một mặt phẳng quản trị tập trung, mang lại kiểm soát tuân thủ cho đội bảo mật và trải nghiệm mượt mà cho người dùng
- Devdatta Akhawe của Figma cho biết khi việc áp dụng MCP tăng lên, XAA giúp doanh nghiệp dễ mở rộng triển khai MCP một cách an toàn hơn
- Tom Moor của Linear nhắc đến trải nghiệm chỉ cần đăng nhập một lần là mọi connector MCP sẽ được tự động thiết lập
Tài liệu và kênh tham gia
- Client, máy chủ và identity platform có thể xem lại đặc tả tiện ích mở rộng và bổ sung hỗ trợ cho tiêu chuẩn mới trong sản phẩm của mình
- Enterprise-Managed Authorization page ghi lại các yêu cầu về luồng dành cho client, máy chủ và máy chủ ủy quyền
- Có thể theo dõi các thay đổi mới nhất và tài liệu hỗ trợ của EMA tại ext-auth repository và draft specification
- EMA Interest Group được dùng cho thảo luận về tiện ích mở rộng, báo cáo khả năng tương thích và cải tiến lặp lại
- EMA là công việc của cộng đồng MCP, với đóng góp từ tác giả SEP-990, các maintainer của kho ext-auth, cùng các nhà cung cấp identity và MCP đã thử nghiệm triển khai ban đầu và thúc đẩy đặc tả tiến lên
1 bình luận
Ý kiến trên Hacker News
Trước khi lại rơi vào cuộc tranh luận quen thuộc kiểu “MCP đã chết, Skills mới là tương lai”, điểm mà MCP thực sự có giá trị hơn skills/CLI là nó tách luồng xác thực ra ngoài cửa sổ ngữ cảnh của agent, và trong một số trường hợp còn ra ngoài cả harness
Điều này hiển nhiên cũng rất quan trọng về mặt bảo mật, đồng thời mang lại trải nghiệm người dùng dễ dàng hơn nhiều khi người dùng phổ thông hoặc các tập đoàn lớn áp dụng công cụ AI
Tôi hiểu những phàn nàn về việc ngữ cảnh phình to hay các lệnh gọi công cụ bị lặp lại, nhưng cấu trúc xử lý xác thực theo cách này rõ ràng có giá trị riêng
Một MCP lý tưởng chỉ cần đóng vai trò cổng xác thực đứng trước API thôi cũng có thể đã đủ mang lại lợi ích lớn
Hiện tại, cách tốt nhất để triển khai skills có vẻ chỉ là kiểu “sao chép tệp này rồi đặt vào đây”, “checkout repository này rồi thêm symbolic link”, hoặc “cài bằng slash command”
Dù đơn giản, nó vẫn không dễ bằng cách triển khai phần mở rộng này để phân phối một máy chủ MCP mới cho nhân viên
Ví dụ, bạn có thể xác thực sẵn 6 tài khoản Linear của 6 khách hàng, rồi thực hiện phân tách trách nhiệm bằng cách chọn tài khoản cần dùng theo phương thức mang tính quyết định và có thể kiểm toán được
Chúng chỉ là những công cụ khác nhau, và tùy yêu cầu mà bên nào có thể phù hợp hơn hoặc không
Nó giống như hỏi giữa dao và cưa thì cái nào tốt hơn
Mỗi khi chủ đề này xuất hiện, các kỹ sư thường hành xử như thể Claude Code là ứng dụng AI agent duy nhất, nhưng ngoài lập trình còn có vô số trường hợp sử dụng trong nhiều ngành nghề khác
Harness có thể không chạy trên máy cục bộ mà trong các container cô lập, bị hạn chế trên đám mây, nơi việc thực thi mã tùy ý là tuyệt đối không được phép
Dù vậy, khi khách hàng muốn kết nối các công cụ hiện có với agent, MCP lại rất phù hợp vì nó cung cấp connector có xác thực tích hợp sẵn, còn skills thì không thuộc phạm vi này
Người dùng phổ thông sẽ không đi tìm thư mục Claude để dán các tệp skill vào
“Connections” thì dễ hiểu hơn, và việc dán MCP vào hoặc tìm trên marketplace cũng dễ hơn
Việc để agent truy cập địa điểm và bài đánh giá có thực sự hữu ích hay không thì vẫn chưa rõ
Xin chúc mừng lớn tới những người đã tạo ra công việc này ở Okta, Anthropic, Microsoft, Figma, Linear và các nơi khác
Ngay cả những người hoài nghi MCP cũng có thứ đáng dùng ở đây
Cơ chế này hoạt động bằng một định dạng token mới là ID-JAG, có tại https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a...
Nó hoàn toàn không dành riêng cho MCP, và ID-JAG có thể được dùng ở bất cứ đâu cần chia sẻ dữ liệu an toàn giữa các ứng dụng dùng cùng một nhà cung cấp SSO
Tôi đang cố gắn xác thực Microsoft Entra ID vào máy chủ MCP đang triển khai, mà thật lòng cảm giác như mình thành kẻ ngốc vậy
Có thể dùng header
WWW-Authenticateđể báo cho client URL metadata của tài nguyên, từ đó cũng có thể chỉ định Microsoft Entra là máy chủ xác thực và cả phạm vi đăng ký ứng dụngNhưng lại không thể chỉ định
client_id, mà theo kiểu mỗi client, tức mỗi agent, tự tạo lấyĐể bắt đầu đăng nhập bằng URL
.../authorizecủa Microsoft Entra thì cần mộtclient_idđã biết khớp với đăng ký ứng dụng trong Entra, chứ giá trị client tự bịa ra thì không đời nào khớp với Entra đượcVề lý thuyết có thể hỗ trợ đăng ký client động, nhưng dĩ nhiên Microsoft Entra không hỗ trợ
Rốt cuộc có vẻ chỉ còn cách dựng một shim đăng ký client động riêng phía trước Microsoft Entra để trả về cùng một
client_idtĩnh cho mọi ngườiKhông rõ giao thức này có thực sự hoạt động trong môi trường doanh nghiệp mà không cần vòng vo gì không, cảm giác như tôi đang bỏ sót điều gì quá hiển nhiên
Entra ID không hỗ trợ đăng ký client động, và tình trạng của hệ sinh thái này hiện vẫn chưa tốt
Thông thường OAuth của MCP được xử lý bằng client truyền thống đã đăng ký trước, nhưng trên thực tế nhiều client MCP lại giả định rằng đăng ký client động là khả dụng nên không cung cấp tùy chọn chỉ định
client_idTuy vậy một số client có hỗ trợ việc này, và tiện quảng bá thì công cụ của chúng tôi là Erato cũng hỗ trợ: https://erato.chat/docs
Các giải pháp phổ biến được triển khai trong doanh nghiệp cũng thường tập trung hóa quyền truy cập MCP qua giao diện web UI, nên hỗ trợ được điều này
Một phương án khác là dùng gateway MCP; giữa gateway và dịch vụ có thể dùng OAuth đăng ký trước, còn giữa gateway và client thì có thể cho phép đăng ký client động
client_id, và về mặt bảo mật thì không muốn bật đăng ký client độngCuối cùng chúng tôi để ứng dụng proxy luồng OAuth và chèn vào một
client_idhardcodeVới client MCP thì giả vờ như có hỗ trợ đăng ký client động, nhưng bên trong vẫn dùng một
client_idđộc lập cho MCP như bình thườngCó ví dụ ở đây: https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...
Sau đó tôi tạo một ứng dụng môi giới xác thực để xử lý đăng ký client bằng OpenID và tạo JWT
Kết quả là có thể quyết định ai được phép dùng công cụ và có những quyền gì dựa trên phòng ban của nhân viên hoặc các tiêu chí khác
Cuối cùng thì vẫn cần đăng ký client động
Họ cũng đang xem xét CIMD, một người anh em mới hơn và tốt hơn của DCR, và đang thảo luận khá sôi nổi, nhưng hiện vẫn chưa cung cấp: https://github.com/FusionAuth/fusionauth-issues/issues/3230
Một phương án thay thế cho proxy mà bạn đề xuất là tạo một
client_idEntra mới với PKCE được bật cho từng client MCP trong cổng dành cho nhà phát triển hoặc tương tự, rồi để người dùng cấu hình giá trị đó trong clientTôi tìm thấy lệnh CLI cho việc này ở đây và có lẽ cũng sẽ có API: https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azur...
Cấu hình Claude Code ở https://code.claude.com/docs/en/mcp, còn cấu hình ChatGPT ở https://developers.openai.com/api/docs/guides/developer-mode
Đăng ký client trước tuy không tối ưu lắm với lập trình viên nhưng vẫn chấp nhận được, và trong đặc tả cũng được xem là một cách tiếp cận hạng nhất: https://modelcontextprotocol.io/specification/2025-11-25/bas...
Nếu người dùng chính là nhân viên nội bộ và họ có thể làm theo hướng dẫn cấu hình để truy cập máy chủ MCP thì cách này vẫn hoạt động
Nhưng nếu đối tượng là các tích hợp công khai rộng rãi, không phải lập trình viên, thì rõ ràng cách đó khó mà chấp nhận được, và đó cũng chính là nơi thể hiện sức mạnh cũng như cơ hội lớn của MCP
Tôi là một trong những người đã xây dựng thứ này tại Anthropic cùng Okta và nhiều đối tác MCP khác
Tôi rất hào hứng khi thấy mô hình này đang định hình trong Claude, và giờ khi EMA đã trở thành một mở rộng ổn định trong đặc tả MCP, tôi cũng muốn mở rộng việc áp dụng sang các nhà cung cấp danh tính và client khác
Nếu có phản hồi, rất mong mọi người để lại ở đây; tôi luôn muốn nghe trải nghiệm sử dụng thực tế và cách có thể cải thiện
Tôi đã không theo dõi MCP một thời gian, nhưng cái này có vẻ rất phù hợp để giúp MCP an toàn hơn trong tổ chức và giải quyết điểm yếu của đăng ký client động
Giờ đây nhà cung cấp danh tính và tổ chức có thể tự cấu hình client và URI chuyển hướng đã được phê duyệt, nên có thể giảm thiểu rộng hơn các cuộc tấn công dựa trên DCR như confused deputy hoặc phishing
Đây cũng là một lợi thế lớn vì nó giảm bớt logic ủy quyền mà trước đây máy chủ MCP phải triển khai trong các trường hợp nhà cung cấp danh tính hoặc tổ chức không hỗ trợ DCR
Điểm trừ là với người dùng phổ thông, có vẻ vẫn cần DCR
Có lẽ có thể giải quyết nếu các nhà cung cấp OAuth phổ thông như GitHub, GitLab, Google hỗ trợ đăng ký tĩnh client/server MCP, client nhúng sẵn
client_idtĩnh, và người dùng đăng nhập bằng nhà cung cấp danh tính đó để tự quản lý kết nốiNhìn chung, XAA/EMA có vẻ vượt trội hơn DCR rất nhiều về cả bảo mật lẫn khả năng sử dụng
Các điểm đáng lo cũng dễ xử lý hơn DCR nhiều và tác động bảo mật nhỏ hơn, vì kẻ tấn công không thể tự đăng ký client của chúng và nhà phát triển máy chủ MCP cũng ít bẫy hơn để mắc phải
Sẽ rất hay nếu có một dạng phiên tạm thời hoặc kho lưu trữ token ngoài băng
Trường hợp sử dụng là trong quá trình bán hàng, bên mua và bên bán phải trao đổi và phân tích rất nhiều thông tin, và việc phân tích này ngày càng mang tính agent hơn
Vấn đề của MCP là độ ma sát thiết lập ban đầu lớn hơn rất nhiều so với việc người dùng tự đăng nhập và lấy thông tin cần thiết
MCP phù hợp với các tương tác đều đặn và thường xuyên, nhưng có nhiều vấn đề với các phiên nhanh, dùng một lần
Sẽ rất tốt nếu trong Claude, khi nói “lấy tài liệu từ X, Y, Z”, Claude có thể truy cập các website đó, và website trả về thông tin sử dụng cơ bản cùng một liên kết đăng nhập để người dùng mở trong trình duyệt
Người dùng xác thực trong trình duyệt, callback trả về một token dùng một lần, sống ngắn và duy nhất, rồi token đó được trao đổi trong các yêu cầu tiếp theo tới website
Làm vậy sẽ cho phép xác thực người dùng nhanh chóng mà vẫn giữ được trạng thái phiên trong quá trình làm việc
Không biết là có thể kỳ vọng sớm hay vẫn sẽ mất khá nhiều thời gian
Có vẻ trường hợp sử dụng chính là nhân viên công ty, nhưng tôi tò mò liệu nó có giá trị tương tự với người dùng không tập trung như khách hàng hoặc người dùng miễn phí cao cấp hay không
Tôi chưa hình dung ra rõ nên muốn biết mình có bỏ sót điều gì không, và có vẻ tôi đã thấy câu trả lời liên quan ở đây: https://news.ycombinator.com/item?id=48594381
Cái này thực sự rất tuyệt
Vài tháng qua tôi khá may mắn khi được làm việc với những người bên MCP về một vài SEP và SDK thử nghiệm bằng Go
Trước đây tôi là kiểu người hoài nghi, hay nói “chẳng phải chỉ là API thôi sao”, “lại thêm một lớp trừu tượng nữa à”
Điều mọi người bỏ lỡ là chữ “P” trong MCP dễ gây hiểu nhầm
Khi xây một ứng dụng truyền thống, bạn phải làm form, UI, xử lý request/response, kênh hai chiều, tác vụ dài hạn, xác thực, v.v.
Với MCP, 80% tầng dùng chung này đã được xử lý, nên MCP vừa là một giao thức nhưng trên thực tế gần như là một framework ứng dụng
Xác thực tích hợp là một cú tăng cường cực lớn, và tôi rất mong chờ những thứ hay ho hơn nữa sắp tới
Khá lạ khi thấy công việc mình làm được nhìn thấy từ bên ngoài
Tôi phụ trách phần triển khai RAS của luồng này tại Atlassian
Chắc chắn sẽ còn nhiều vòng cải tiến lặp lại trong luồng này, như CIMD, hỗ trợ tenancy tốt hơn, v.v.
Tất cả những người ở Anthropic, Okta và Atlassian đã chuyển tải thứ này đều rất xuất sắc
Giá mà nó hỗ trợ web để có thể просто phát hành cookie dài hạn thì tốt biết mấy
Tôi đã phải hack đặc tả để chuyển cookie qua bắt tay OAuth nhằm làm việc này mà không cần máy chủ OAuth
Việc không muốn cho phép kiểu này thực sự rất bực bội
Nếu không có cookie thì mở trang web lên, khi cookie được thiết lập thì đóng lại và lưu vào là xong
Tôi thậm chí còn viết cả một cuốn minibook 80 trang về MCP, mà vẫn thấy bực bội không thôi
Nó có vấn đề cả về khả năng sử dụng lẫn bảo mật, và cookie được tạo ra cho trình duyệt
Máy chủ và client MCP thường chạy trong những môi trường không đảm bảo có trình duyệt
Thông tin xác thực dài hạn là một gánh nặng trách nhiệm rất lớn
Tôi đã đọc đi đọc lại vài lần, và rõ ràng nó rất hữu ích
Bạn có thể tập trung kiểm toán và kiểm soát truy cập vào một nhà cung cấp danh tính duy nhất, và nhà cung cấp danh tính thậm chí có thể hoạt động như một proxy API gateway đảm nhận việc trao đổi token khi cần
Đây là cách tiếp cận mà những bên khác trong lĩnh vực này cũng đã áp dụng
Cá nhân tôi thấy hơi không thoải mái ở chỗ nhà cung cấp danh tính có thể ủy quyền quyền hạn của tôi cho client khi tôi không hề nhận biết
Có lẽ là vì tôi đã quá quen với các luồng có sự hiện diện của người dùng trong trình duyệt, và cảm giác như mọi thứ đang dần tiến hóa thành việc tập trung hóa quyền truy cập cho máy móc
Trong môi trường doanh nghiệp, điều này có thể chấp nhận được vì danh tính thuộc về công ty hơn là cá nhân
Nhưng tích hợp vào mảng customer identity lại là một bài toán hoàn toàn khác, và có lẽ không dễ để xây dựng kiểu lòng tin này giữa nhà cung cấp danh tính, client và máy chủ ủy quyền tài nguyên
Ví dụ, chỉ cần tạo một quan hệ tin cậy để nếu bạn đã đăng nhập GitHub thì cũng tự động đăng nhập vào Sentry
Vẫn còn nhiều việc phải làm về sau, nhưng như bạn nói, trường hợp sử dụng rõ ràng nhất hiện tại vẫn là doanh nghiệp
Quản trị viên không muốn từng nhân viên tự bấm lung tung khắp nơi rồi chọn các loại thông tin xác thực tùy tiện
Ở C1, xác thực MCP là một vấn đề đau đầu lớn cả với việc dùng MCP nội bộ lẫn MCP Gateway trong sản phẩm, nên việc này được đưa vào thật sự rất đáng mừng
Hôm nay C1 đã phát hành hỗ trợ để hoạt động như một nhà cung cấp định danh EMA và cấp các token phạm vi giới hạn có thời gian sống ngắn
Giờ tôi muốn kết nối với Linear và các MCP khác mà chúng tôi dùng để thoát khỏi các luồng OAuth lặp đi lặp lại
Claude từ lâu đã xử lý kiểu này như phép màu với một số connector tích hợp sẵn, ít nhất là với Slack, và trải nghiệm khá tốt
Nói rõ luôn, tôi là VPE của C1, và đã tài liệu hóa cách tiếp cận cho những ai muốn đào sâu: https://www.c1.ai/docs/product/admin/enterprise-managed-auth...
Tôi vẫn chưa thật sự hiểu nó có lợi thế gì so với OAuth thông thường
Có lẽ cần một ví dụ so sánh luồng ủy quyền
Điều này hợp lý với các trường hợp sử dụng cho người tiêu dùng, tức là khi người dùng cuối sở hữu dữ liệu của chính họ
Nhưng trong nhiều trường hợp sử dụng doanh nghiệp, bên cần chia sẻ dữ liệu và kiểm soát quyền truy cập không phải người dùng cuối mà là công ty
Nếu tôi là nhân viên của Acme, tôi không nên là người quyết định có kết nối dữ liệu Google Drive của Acme với Claude hay ChatGPT hay không; đó phải là quyết định của bộ phận IT
Enterprise-Managed OAuth, hay Cross App Access (XAA), đưa mô hình chia sẻ do quản trị viên IT kiểm soát tập trung vào trong framework OAuth để nó vẫn hoạt động cùng hệ sinh thái hiện có
Ngoài ra, khi việc quản lý đồng ý chia sẻ dữ liệu được chuyển từ nhân viên sang quản trị viên IT, lợi ích về trải nghiệm người dùng cũng rất lớn
Nhân viên không cần đi qua nhiều luồng OAuth để kết nối tài khoản, vì quản trị viên IT đã thiết lập sẵn các quyền kiểm soát chia sẻ
Hãy hình dung ngay ngày đầu đi làm, Slack đã được kết nối sẵn với Zoom, Drive, Calendar, v.v.
Vì quyết định ủy quyền truy cập được đưa ra ở cấp chính sách của nhà cung cấp định danh
Người dùng thậm chí có thể sẽ không bao giờ biết ứng dụng hay dịch vụ nào đã được cho phép chia sẻ thông tin của họ
Khoan đã, đó thật sự là ưu điểm sao? ;-)