One Login to Rule Them All: Cross-App Access for MCP — Garrett Galow, WorkOS

• MCP (Multicloud Platform) hiện tại gặp vấn đề về trải nghiệm người dùng với các màn hình chấp thuận liên tục và rủi ro bảo mật do OAuth không phù hợp với mô hình SSO hiện đại của doanh nghiệp.
• Giải pháp Cross-App Access (XAA) cho phép Identity Provider (IDP) đóng vai trò là nhà cung cấp sự tin cậy trung tâm, bắc cầu giữa các ứng dụng (client và server) MCP.
• Điều này giúp tự động hóa quá trình xác thực và ủy quyền giữa các ứng dụng, loại bỏ màn hình chấp thuận thủ công, cải thiện tư thế bảo mật bằng cách quản lý vòng đời mã thông báo hiệu quả hơn và tăng cường khả năng quan sát cho nhóm IT.

• Việc sử dụng MCP hiện tại gây khó chịu cho người dùng (do liên tục phải duyệt màn hình chấp thuận) và tạo ra rủi ro bảo mật cùng thách thức quản lý cho nhóm IT (thiếu khả năng quan sát, mã thông báo truy cập tồn tại lâu dài).
• Giao thức OAuth cơ bản, được thiết kế cho các hệ thống không tin tưởng lẫn nhau, không phù hợp với mô hình Single Sign-On (SSO) trong môi trường doanh nghiệp hiện đại.
• Cross-App Access (XAA) giải quyết vấn đề bằng cách cho phép nhà cung cấp danh tính (IDP) hoạt động như một bên tin cậy, giúp các ứng dụng MCP client và MCP server giao tiếp và cấp thông tin xác thực một cách tự động.
• Quá trình XAA bao gồm MCP client yêu cầu một mã thông báo IDJag từ IDP, sau đó sử dụng mã thông báo này để đổi lấy mã thông báo truy cập tiêu chuẩn từ máy chủ ủy quyền của MCP server.
• Lợi ích chính của XAA là loại bỏ sự cần thiết của màn hình chấp thuận thủ công, rút ngắn vòng đời mã thông báo truy cập để tăng cường bảo mật, và cung cấp cho IT khả năng thu hồi truy cập tức thì.
• Để triển khai XAA, quản trị viên IT cần cấu hình chính sách trong IDP để cho phép các ứng dụng cụ thể yêu cầu truy cập lẫn nhau.
• MCP client phải tích hợp SSO tương thích XAA và hỗ trợ luồng yêu cầu/trao đổi mã thông báo IDJag.
• MCP server cần hỗ trợ loại JWT bearer mới và có khả năng xác minh mã thông báo IDJag với nhà cung cấp danh tính.

• cross-app access (XAA) — truy cập đa ứng dụng
• MCP — Nền tảng/Cơ chế đa ứng dụng (thường dùng cho AI agents và tích hợp dịch vụ)
• consent screens — màn hình chấp thuận
• Identity Provider (IDP) — Nhà cung cấp danh tính
• Single Sign-On (SSO) — Đăng nhập một lần
• IDJag token — mã thông báo IDJag (một loại token ủy quyền giữa các ứng dụng được cấp bởi IDP)
• access token — mã thông báo truy cập
• security posture — tư thế bảo mật
• observability — khả năng quan sát
• token lifecycle — vòng đời mã thông báo

Chào buổi sáng mọi người. Cảm ơn các bạn đã đến với buổi nói chuyện này. Hy vọng buổi sáng của các bạn đã diễn ra suôn sẻ. Tôi đã kịp nghe một phần bài phát biểu chính và tuy không nghe được toàn bộ, nhưng nó khá hay. Tên tôi là Gary Galo. Hôm nay tôi sẽ nói về "Một lần đăng nhập để quản lý tất cả" (One Login to Rule Them All), hay còn gọi là cross-app access cho MCP, phòng trường hợp các bạn chưa nghe về nó.

Giới thiệu về diễn giả và WorkOS

Một chút giới thiệu về bản thân: tôi điều hành bộ phận sản phẩm tại WorkOS. Tôi đã xây dựng các nền tảng nhà phát triển (developer platforms) dành cho doanh nghiệp (enterprise) trong gần 15 năm qua, ban đầu là ở Microsoft Azure, sau đó là Cloudflare trong một thời gian dài, và bây giờ là WorkOS. Nếu các bạn chưa từng nghe về WorkOS, chúng tôi giúp ứng dụng (app) của bạn và cả các tác nhân (agents) của bạn sẵn sàng cho doanh nghiệp. Chúng tôi cung cấp xác thực (authentication) cho những công ty như Anthropic, Cursor, OpenAI. Vì vậy, nếu bạn đã từng đăng nhập vào Cursor, chẳng hạn, dù là bằng tên người dùng (username)/mật khẩu (password) hay một IDP doanh nghiệp (enterprise IDP), bạn đã sử dụng WorkOS. Hôm nay tôi sẽ nói về MCP và việc đăng nhập thông qua các hệ thống (things) như Anthropic và Cursor.

Vấn đề với các màn hình chấp thuận của MCP

Nhưng trước hết, nếu bạn sử dụng MCP một cách rộng rãi, bạn sẽ biết rằng nó đòi hỏi liên tục các màn hình chấp thuận (consent screens). Ai ở đây thường xuyên sử dụng máy chủ MCP (MCP server)? OK, hầu hết các bạn.

Nếu bạn chưa từng trải nghiệm điều này trước đây, đây là Cursor mà tôi đã thiết lập. Và nếu bạn muốn sử dụng máy chủ MCP với Cursor, bạn thêm nó vào menu, bạn có một tệp cấu hình (config file) nhỏ. Và sau đó, trong mỗi cái này, nếu bạn muốn sử dụng, bạn phải kết nối. Nó sẽ bật lên một cửa sổ (window). Bạn có một màn hình chấp thuận nhỏ xinh mà bạn sẽ không đọc. Bạn chỉ cần nói OK, và bạn sẽ được chuyển hướng trở lại. Và bạn cần làm điều này cho mỗi công cụ (tool) duy nhất, điều này thành thật mà nói khá khó chịu. Và đôi khi bạn phải làm lại điều này. Bạn không thực sự biết tại sao. Đôi khi nó dường như quên rằng bạn đã làm điều này rồi. Vâng, và đây là một việc bạn phải làm mỗi khi muốn sử dụng các máy chủ MCP này. Và điều đó không hề vui vẻ.

Bất tiện cho nhà phát triển và nhóm IT

Nhưng trong một công ty có nhiều nhà phát triển (developers), đó không chỉ là sự bất tiện của một người. Với tư cách là một người dùng (user), bạn có thể đăng nhập vào nửa tá hoặc một tá máy chủ MCP. Nhưng khi bạn kết hợp điều đó trên toàn nhóm (team) của mình, về cơ bản bạn có hàng chục người dành tất cả thời gian này để quản lý tất cả các màn hình chấp thuận này, nhấp vào các nút (buttons) này mà không thực sự quan tâm tại sao họ phải làm điều này.

Hiện tại, đây là một di tích của nhiều công nghệ mà MCP quyết định sử dụng. Nó sử dụng OAuth làm lớp xác thực (authentication layer) cơ bản. Và cách OAuth được phát minh ban đầu dựa trên ý tưởng rằng hai hệ thống này không tin tưởng lẫn nhau. Vì vậy, bạn phải cung cấp sự chấp thuận (consent) này để nói rằng, "Vâng, Cursor có thể truy cập (access) vào tài khoản Figma của tôi. Vâng, Cursor có thể truy cập vào tài khoản Notion của tôi."

Nhưng thực tế không phải là cách mọi thứ hoạt động ngày nay. Đó không phải là cách các công ty hoạt động. Chúng ta có một thứ gọi là single sign-on (SSO). Hầu hết mọi người đều đang sử dụng nó. Nếu bạn có một công ty, bạn đang đăng nhập thông qua một hệ thống nào đó, như Okta hoặc Microsoft Intra, một trong các hệ thống này. Và ý tưởng "một lần đăng nhập vào tất cả các ứng dụng đó" đã hoạt động rất tốt.

Nhưng MCP phá vỡ mô hình (model) này. Nó dường như giả định rằng không có ứng dụng nào trong số này biết gì về nhau. Không có cách nào để biết rằng bạn là cùng một người và nên có quyền truy cập vào các hệ thống này. Vì vậy, bạn phải trải qua các luồng (flows) này hết lần này đến lần khác.

Điều đó thực sự khó chịu. Và có lẽ bản thân điều đó là một vấn đề đáng để giải quyết. Nhưng con người sẽ chịu đựng nhiều sự khó chịu nếu họ nhận được giá trị (value) từ nó. Vấn đề thực sự nằm ở nhóm IT (IT team). Những người quản lý tất cả các ứng dụng này, MCP không hoạt động theo cách họ muốn. IT không thể thực sự biết bạn có thể đang sử dụng dịch vụ MCP nào. Bạn đang kết nối với những thứ (things) tùy tiện này. Bạn không nhất thiết phải thông qua IDP đó để kết nối với chúng, điều này gây ra vấn đề.

Về cơ bản, họ không thể xác định tác nhân AI nào bạn thực sự có thể sử dụng. Về lý thuyết, bạn có thể sử dụng bất kỳ máy khách MCP (MCP client) tùy ý nào. Đó có thể là Cursor, nhưng bạn cũng có thể đang sử dụng DeepSeek hoặc một số công cụ khác mà nhóm IT của bạn có thể không muốn bạn sử dụng. Và bạn đang cấp quyền truy cập vào những hệ thống nhạy cảm này. Bạn có rất nhiều dữ liệu trong các ứng dụng như Figma hoặc Notion mà IT có thể không muốn bất kỳ tác nhân AI nào có quyền truy cập.

Một vấn đề khác là quyền truy cập và bảo mật (security) thực tế. Tôi không biết có bao nhiêu người đã nghe về gói NPM Axios bị tấn công khoảng một tuần trước. Thật không may, tôi đã bị ảnh hưởng bởi sự cố đó. Tôi vẫn chưa chắc chắn chính xác gói NPM nào tôi đã sử dụng có phụ thuộc (dependency) đó. Nhưng nhóm IT của chúng tôi đã nhận biết được vấn đề đó. Họ đã có thể phát hiện rằng máy (machine) của tôi đã bị xâm nhập (compromised). Họ đã có thể cắt truy cập mạng (network access) vào máy của tôi. Họ có thể vô hiệu hóa các phiên Okta (Okta sessions) của tôi trên tất cả các ứng dụng để giúp bảo mật tài khoản (account) của tôi và dữ liệu công ty (company data) của chúng tôi.

Nhưng trên máy cục bộ (local machine) của tôi, tôi đã kết nối các MCP server. Tôi có Khóa API (API keys) mà tôi đang sử dụng cho một số việc nhất định. Đó là điều chúng tôi thực sự phải giải quyết. Tôi đã xem xét máy tính xách tay (laptop) của mình và tự hỏi, "Mình đã kết nối nó với cái gì? Mình có thể có những dịch vụ (services) nào khác? Có thông tin xác thực (credential) nào không đến từ IDP đang có nguy cơ bị rò rỉ không?" Làm thế nào để chúng tôi thu hồi những quyền đó? Làm thế nào để chúng tôi đảm bảo hệ thống của tôi an toàn? MCP ngày nay sử dụng OAuth, nếu điều gì đó như vậy xảy ra hoặc bạn rời công ty, IT có thể thu hồi single sign-on của bạn thông qua IDP đối với các ứng dụng đó. Bạn vẫn có các mã thông báo truy cập (access tokens) này, các mã thông báo làm mới (refresh tokens) này, ngay cả trong hầu hết các trường hợp, chúng cung cấp cho bạn quyền truy cập liên tục vào các dịch vụ này. Điều đó có nghĩa là bạn có thể có quyền truy cập trong nhiều ngày, nhiều tuần hoặc thậm chí nhiều tháng. Nhiều công ty không sử dụng những thứ như SCEM, cho phép bạn thu hồi quyền truy cập đó hoàn toàn. Và điều đó có nghĩa là bạn có vấn đề về quyền truy cập kéo dài mà IT không có khả năng quan sát (observability) được.

Và sau đó, một lần nữa, mỗi khi có ai đó gia nhập nhóm, họ phải trải qua toàn bộ quá trình này, nơi IT có thể thiết lập tự động các MCP server bạn đang sử dụng trong những ứng dụng như Cursor hoặc Claude. Nhưng bạn vẫn cần phải tự mình thực hiện tất cả xác thực và quản lý tất cả các kết nối (connections) này. Rõ ràng, điều này không tốt.

Giới thiệu Cross-App Access (XAA)

Vậy chúng ta đang làm gì về nó? Giải pháp cho vấn đề này là gì? Giải pháp là cross-app access, còn được gọi là XAA. XAA về cơ bản là một cách mà nhà cung cấp danh tính (identity provider) có thể đóng vai trò là một bên thay thế (stand-in), một nhà cung cấp sự tin cậy (trust provider) giữa các ứng dụng.

Vì vậy, hãy lấy ví dụ về Cursor (tôi là người dùng), đó là máy khách MCP của tôi. Figma là MCP server tôi muốn kết nối, và sau đó Okta là IDP mà chúng tôi sử dụng tại công ty để đăng nhập vào các hệ thống. Vì vậy, cả Cursor và Figma đều đã có mối quan hệ tin cậy (trust relationship) này với Okta. Để đăng nhập vào Cursor, tôi đi qua Okta; để đăng nhập vào Figma, tôi cũng đi qua Okta. Vì vậy, cả hai ứng dụng này đều biết về workOS.okta.com. Chúng biết về tôi với tư cách là một người có quyền truy cập vào các ứng dụng này.

Điều mà cross-app access làm là giúp thu hẹp khoảng cách giữa Cursor và Figma. Bằng cách cung cấp một cách để Cursor giao tiếp với Figma, cả hai có thể dựa vào mối tin cậy đó vào Okta. Và họ có thể nhận được thông tin xác thực được cấp mà không cần can thiệp thủ công (manual) hay con người (human intervention).

XAA trong thực tế (Demo)

Vậy để tôi cho các bạn thấy một chút về điều đó trông như thế nào. Vậy tôi sẽ chuyển sang thiết bị đầu cuối (terminal) của mình và làm cho nó lớn hơn, dễ nhìn hơn.

Vậy ở đây, bên trái trên thẻ (tab) này, tôi có cài đặt Claude Code thông thường. Và nếu tôi kiểm tra các MCP server của mình, tôi đã kết nối server Figma ở đây. Rõ ràng nó cần xác thực. Tôi có thể thực hiện quy trình đó. Nó sẽ hiển thị một màn hình chấp thuận. Đó là luồng tiêu chuẩn.

Trong cửa sổ này, chúng ta có một phiên bản Claude Code tương thích với XAA, về cơ bản đã triển khai XAA ở đây. Vậy điều đầu tiên tôi làm để minh họa, vì đây là một triển khai beta (beta implementation) của điều này, tôi có thể nói rằng tôi đã cấu hình bên trong Claude Code kết nối này với môi trường Okta của tôi. Và điều đầu tiên tôi sẽ làm ở đây là tôi sẽ đăng nhập. Vì vậy, đây là việc đăng nhập Okta. Tôi sẽ đăng nhập vào môi trường Okta của tôi. Đây là điều bạn cần làm một lần để, nếu bạn đang thiết lập Claude lần đầu tiên, bạn sẽ đăng nhập vào Okta. OK, mọi thứ đã hoàn tất.

Và bây giờ, nếu tôi khởi động Claude và nhìn vào các MCP server của tôi, chúng ta sẽ nhận thấy rằng Figma đã tự động kết nối. Để tôi thử phóng to nó một chút. Và vì vậy tôi không phải làm gì cả. Tôi không phải nhìn thấy một màn hình chấp thuận. Figma đã tự động kết nối. Và bây giờ với Figma hoặc một danh sách các MCP server của chúng ta, tôi có thể làm tất cả những điều đó. Tôi biết điều đó có vẻ như ma thuật. Tôi thực sự không phải nhấp vào bất cứ thứ gì. Tôi có thực sự làm gì không? Hứa là có.

Cách XAA hoạt động: Đằng sau hậu trường

Hãy để tôi nói một chút về những gì thực sự đang diễn ra đằng sau hậu trường. Toàn bộ điểm mấu chốt của điều này là bạn không phải làm gì cả. Nó xuất hiện như thể tự động. Nhưng đây là cách nó hoạt động.

Vì vậy, trong tình huống này, chúng ta sẽ nói về bốn hệ thống. Máy khách (client), trong trường hợp đó là Claude Code mà tôi đang sử dụng. Nhà cung cấp danh tính (identity provider), là Okta. Máy chủ ủy quyền tài nguyên (resource authorization server), trong trường hợp này được quản lý bởi Figma. Nhưng chúng ta đang tách nó ra khỏi máy chủ tài nguyên (resource server), đó là API Figma. Nếu bạn không quen thuộc với MCP, bạn sẽ có máy chủ tài nguyên giống như MCP server của bạn. Nó sẽ gọi đến một nơi riêng biệt để thực hiện ủy quyền (authorization) và cấp mã thông báo (tokens).

Vì vậy, trong trường hợp này, điều đầu tiên tôi đã làm là đăng nhập Okta. Vì vậy, người dùng đi qua SSO đến IDP. Và điều đó sẽ cấp lại một mã thông báo ID (ID token) và mã thông báo làm mới (refresh token). Vì vậy, trong trường hợp này, Claude giữ các mã thông báo đó. Và nó có thể sử dụng điều đó trong bước (step) tiếp theo để yêu cầu cái gọi là mã thông báo IDJag. IDJag là tên của đặc tả (spec) mà tất cả các công nghệ (technologies) được xây dựng dựa trên đó: Sans4IdidityJWTAuthorizationGrant. Nghe rất dài dòng. Về cơ bản, nó chỉ có nghĩa là một mã thông báo được cấp bởi IDP có thể được sử dụng trên các dịch vụ để quản lý quyền truy cập.

Vì vậy, máy khách quay lại IDP và nói, "Này, tôi có mã thông báo làm mới này cho Garrett. Bạn có thể vui lòng cấp cho tôi mã thông báo IDJag này để hoạt động với Figma không?" Okta về cơ bản biết về Claude. Nó biết về Figma. Nó có thể kiểm tra, "Này, Garrett có phải là người dùng của cả hai ứng dụng này không? Hay tôi có được phép làm điều này không? Tôi có được phép cấp mã thông báo cho Claude thay mặt cho Figma không?" Câu trả lời là có. Okta sẽ gửi lại mã thông báo IDJag này cho Claude Code.

Sau đó, Claude gửi điều đó đến Figma. Trong trường hợp này, máy chủ ủy quyền của Figma nói, "Này, tôi có mã thông báo IDJag này cho Garrett từ phiên bản Okta (Okta instance) của WorkOS. Bạn có thể vui lòng xác thực điều này và cung cấp lại cho tôi một mã thông báo không?" Figma, vì nó có mối quan hệ này với Okta, sẽ tiến hành xác minh IDJag. Sau khi được xác minh và chính xác, nó sẽ có thể cấp lại mã thông báo truy cập này cho Claude Code.

Và tại thời điểm đó, bước bốn ở đây là luồng OAuth (OAuth flow) MCP thông thường. Vì vậy, nó chỉ bắt đầu giao tiếp với MCP server. Nó đang sử dụng một mã thông báo truy cập thông thường. Đó không phải là một loại thông tin xác thực mới. Và bây giờ tôi có thể giao tiếp với MCP server Figma, cấp phản hồi (responses), và chúng ta đã sẵn sàng.

Lợi ích về bảo mật và vòng đời mã thông báo

Một vài điều quan trọng ở đây. Bước hai và ba ở đây hoàn toàn vô hình đối với người dùng. Khi tôi đã đăng nhập vào IDP, điều mà tôi không phải làm thường xuyên, đó có thể là một lần một ngày. Điều đó tùy thuộc vào IT, các chính sách (policies) của công ty bạn. Có thể đó là một lần một ngày, có thể là một lần một tuần. Khi bạn đã thực hiện đăng nhập đó, bạn không phải làm lại điều đó. Bước hai và ba được thực hiện đằng sau hậu trường. Và sau đó bước bốn chỉ là yêu cầu mã thông báo truy cập (access token request) thông thường mà bạn đang thực hiện đối với MCP server.

Một điều khác xung quanh vấn đề này là, trong trường hợp mã thông báo truy cập đang được cấp, nó có thể có thời gian tồn tại (lived) rất ngắn. Vì vậy, hầu hết các ứng dụng cấp mã thông báo truy cập có thời gian tồn tại khoảng năm phút. Và điều xảy ra là mã thông báo đó sẽ hết hạn sau năm phút. Nhưng bạn không cần con người phải làm bất cứ điều gì. Về cơ bản, bạn có thể chạy lại luồng IDJag này cộng với trao đổi (exchange) và nhận mã thông báo truy cập mới khi cần. Và vì vậy, miễn là phiên (session) của bạn đang hoạt động. Bạn có thể tiếp tục nhận các mã thông báo IDJag này, trao đổi lấy các mã thông báo truy cập. Và vì vậy bạn thực sự có một tư thế bảo mật (security posture) tốt hơn khi có điều gì đó xảy ra.

Quản lý truy cập và kết nối máy chủ MCP

Khi quyền truy cập của tôi bị gỡ bỏ vì lý do nào đó, hoặc phiên làm việc của tôi bị khóa với Octa, khi access token đó hết hạn, tôi sẽ không thể truy cập lại được. Tôi sẽ không thể kết nối lại với MCP server đó. Vì vậy, tôi muốn đi sâu một chút vào việc, điều này trông như thế nào ở phía thiết lập? IT admin của bạn cần làm gì nếu bạn đang chạy một MCP client? Bạn cần làm gì nếu bạn đang chạy một MCP server?

Yêu cầu đối với quản trị viên IT

Về phía IT, nó thực sự khá đơn giản. Bạn sẽ đã có một ứng dụng Claude Code hoặc Cursor Octa được tạo. Bạn sẽ đã có ứng dụng FidMAS SSO được tạo. Đó sẽ là những thứ công ty bạn đã có sẵn. Bên trong một hệ thống như Octa, có một cổng kết nối được quản lý mới, nơi bạn có thể vào và nói, "Tôi muốn cấp khả năng yêu cầu truy cập ứng dụng nào cho ứng dụng khác?"

Vì vậy, trong trường hợp này, chúng ta nói Cursor có thể yêu cầu truy cập vào Figma. Và chính sách đó có nghĩa là khi Cursor đến và hỏi, "Này Octa, tôi có thể có một ID Jag token cho Figma không?", một phần của yêu cầu đó là hệ thống nào mà nó muốn truy cập. Octa có thể xác minh điều đó và nói, "Vâng, thực ra, Cursor được phép yêu cầu quyền truy cập này từ Figma," và cấp token đó. Vậy đó là tất cả những gì bạn cần làm ở phía IT. Khi bạn đã làm xong, mọi thứ khác sẽ như bình thường. Người dùng phải thuộc về cả hai ứng dụng. Bạn đang thực hiện cùng một policy quản lý như bạn vẫn làm.

Yêu cầu đối với MCP Client

Về phía MCP client (đây sẽ là Claude Code của bạn, Cursor của bạn, nếu bạn đang xây dựng MCP client của riêng mình), có một số điều bạn cần làm:

1. Bạn cần có một kết nối SSO tương thích XA. Nói chung, nếu bạn đang hỗ trợ SSO trong ứng dụng hoặc client của mình, đó là tiêu chuẩn chung. Hỗ trợ XA tương đối mới, nên Octa có hỗ trợ nó với một số hạn chế. Họ đang khắc phục những hạn chế đó. Chúng tôi đang làm việc với các đối tác công nghiệp khác như Microsoft để họ cũng hỗ trợ điều này.
2. Kết nối IDP của khách hàng đó cần phải tương thích và được bật XA. Client của bạn yêu cầu ID Jag token này từ identity provider. Bạn nhận lại token đó.
3. Bạn cần thực hiện yêu cầu trao đổi đó với các MCP server. Bạn cần hỗ trợ token flow đó.
4. Khi điều đó được thực hiện, thứ tư là tiêu chuẩn của bạn: chỉ cần nói chuyện với một MCP server.

Vì vậy, không có gì mới ở đó. Chúng tôi đã xây dựng hỗ trợ, với tư cách là nhà cung cấp authentication services cho khách hàng của mình. Chúng tôi đã xây dựng hỗ trợ cho các điểm một, hai và ba. Vì vậy, chúng tôi có thể xử lý việc xây dựng của bạn. Trong MCP client, chúng tôi có thể xử lý tất cả flow đó. Chúng tôi thực sự là cách mà Cursor và Anthropic đang làm điều này vì họ sử dụng chúng tôi cho các kết nối SSO của họ.

Yêu cầu đối với MCP Server

Về phía MCP server (có lẽ liên quan hơn đến hầu hết mọi người, vì bạn có thể có một MCP server mà khách hàng của bạn sử dụng), cũng có một số thứ bạn cần hỗ trợ:

1. Có kiểu JWT bearer mới mà bạn cần hỗ trợ. Về cơ bản, điều này thông báo rằng bạn hiện hỗ trợ ID Jag flow này và bạn sẽ chấp nhận các loại token này.
2. Các MCP client sẽ gửi cho bạn những token đó. Bạn thường chấp nhận chúng, và sau đó bạn cần xác minh chúng.
3. Có một bước mà bạn truy cập identity provider của Octa URL và hỏi, "Này, đây có phải là một token hợp lệ không?" Về cơ bản, đó là một JWT đã ký, giống như cách bạn xác thực một JWT trong bất kỳ ngữ cảnh nào khác. Bạn đang làm điều tương tự ở đây.
4. Cuối cùng, điều mà lẽ ra phải là bình thường, là cấp access token. Vậy bạn đã xác thực mọi thứ. Bây giờ bạn muốn cấp cho họ một access token.

Tìm hiểu thêm về ID Jag

Nếu bạn muốn tìm hiểu thêm về cách hoạt động của nó, tôi đã trình bày đây như một overview cấp cao. Rõ ràng, có một spec đầy đủ định nghĩa về ID Jag và các chi tiết cụ thể về cách nó nên hoạt động. Đó là một bài tập tôi dành cho bạn, người đọc, nếu bạn muốn khám phá spec. Tôi sẽ nói rằng Claude rất giỏi trong việc giải thích spec, vì vậy đó có thể là một cách dễ dàng hơn để làm quen mà không cần phải đọc, bạn biết đấy, IETF nomenclature. Nhưng ở đây chúng tôi có một blog post trình bày tất cả các chi tiết xung quanh ID Jag, cách nó hoạt động, và nhiều khía cạnh kỹ thuật hơn nếu bạn quan tâm. Vì vậy, bạn có thể kiểm tra nó để tìm hiểu thêm.

Hỏi & Đáp: Xác thực và ủy quyền

Với đó, tôi rất vui được trả lời bất kỳ câu hỏi nào mọi người có.

Câu hỏi: Điều này giải quyết authentication, không phải authorization. Liệu nó có giúp ích gì cho authorization không?

Trả lời: Mặc định là không. Vì vậy, điều này chỉ xoay quanh khía cạnh authentication. Điều này vẫn là, bạn đăng nhập vào Figma với tư cách của chính bạn, vì vậy bạn nhận được các permissions mà bạn có với Figma. Một trong những điều chúng tôi đang thảo luận là, "Vậy, làm thế nào để mở rộng điều này để có thể định nghĩa access có phạm vi?" Có thể Octa đang nói, "Vâng, tôi sẽ cấp quyền truy cập này," nhưng có những hạn chế đi kèm với các permissions mà tôi sẽ cấp. Điều đó không phải là một phần của spec hiện nay, nhưng rõ ràng, đó là điều quan trọng mà chúng ta cần xem xét.

Câu hỏi: Làm thế nào MCP client biết được ứng dụng mà nó đang yêu cầu access từ Octa?

Trả lời: Câu trả lời về cơ bản là một audience URL. Vì vậy, trong trường hợp này, bạn sẽ sử dụng mcp.figma.com, là MCP server của Figma. Audience đó sẽ được biết bên trong Octa. Và do đó, Cursor của bạn sẽ yêu cầu Octa và nói, "Này, đây là audience tôi đang tìm kiếm." Điều đó được cấu hình bên trong Octa để nói rằng, "Ứng dụng Figma bao gồm audience này." Và sau đó đó là cách nó kiểm tra yêu cầu access.

[Câu hỏi không rõ ràng, có thể là 'Mục đích sử dụng của bạn là gì?'] Không, tôi không nghĩ bạn có thể sử dụng nó để hack scopes, bởi vì đó chỉ là audience, vốn là một thuật ngữ OAuth tiêu chuẩn. Vì vậy, Cursor biết audience mà nó đang cố gắng lấy dựa trên MCP server. Octa được cấu hình để biết rằng đối với ứng dụng này, đó là audience mà nó kiểm soát. Và sau đó, rõ ràng, Figma biết audience của riêng mình và đang kiểm tra tính hợp lệ của JWT với Octa.

Hỗ trợ XA và tiêu chuẩn mới

Tuyệt vời. Vâng. Nó được hỗ trợ bởi Intra. Microsoft vẫn chưa thêm hỗ trợ XA bên trong Intra. Đó là điều chúng tôi đang làm việc với họ. Nếu bạn có các mối liên hệ, hãy thúc đẩy họ, bởi vì chúng tôi muốn điều này được áp dụng rộng rãi hơn. Nói chung hơn, hiện tại với Octa, nó được hỗ trợ cho các kết nối dựa trên OIDC, nhưng họ cũng sẽ hỗ trợ điều này cho các kết nối dựa trên SAML. Spec định nghĩa rằng bất cứ thứ gì bạn gửi đến IDP, đó là một refresh token, một ID token hoặc một SAML assertion. Vì vậy, đó chỉ là một thứ gì đó chứng minh rằng người dùng có một session trong ứng dụng của bạn. Đó là phần duy nhất quan tâm đến loại kết nối SSO mà bạn có. Nhưng vâng, hiện tại chỉ có Octa. Hy vọng sẽ sớm có thêm.

[Xác nhận] Không, họ chưa hỗ trợ nó. [Câu hỏi tiếp theo về việc Cursor/Claude nói chuyện với Microsoft để single sign-on] Vâng, tôi có thể cần nói chuyện với bạn sau phần này. Nó hơi phức tạp. Nếu có một kết nối dựa trên OIDC, thì các scopes mà client đang yêu cầu cần phải khớp với những gì server sẽ cho phép. Và nếu có sự không khớp ở đó, có nhiều cách khác nhau để bạn xử lý, nhưng rõ ràng bạn không nên cấp các scopes không được phép. Vì vậy, đó có thể là vấn đề.

DCR và CIMD: Các vấn đề và giải pháp

Câu hỏi: Liệu Intra có được hỗ trợ cho DCR không, và liệu điều đó có tạo ra vấn đề không?

Trả lời: Vâng, đó là một vấn đề chung, tôi nghĩ vậy, trong thế giới thực: client nào hoặc server nào hỗ trợ tất cả MCP spec khi nó phát triển. Vì vậy, tôi sẽ nói rằng hầu hết các client dự kiến sẽ hỗ trợ DCR vào thời điểm này, nhưng rõ ràng không phải tất cả đều làm vậy. Và bạn không thể làm được nhiều nếu một bên không hỗ trợ nó; bạn phải đi đăng ký. Trong trường hợp DCR không được hỗ trợ, bạn phải đăng ký trước client đó. CIMD là tiêu chuẩn mới thay thế DCR. (Tôi thực sự quên CI là viết tắt của từ gì, nhưng nó giống như một tài liệu trung gian xác định client trước để bạn không phải tạo client mỗi lần.) Nhưng tiêu chuẩn đó thậm chí còn ít được hỗ trợ rộng rãi hơn trong ecosystem vì nó mới chỉ khoảng ba tháng tuổi. Nhưng đó là một experience tốt hơn. Vì vậy, vâng, vẫn còn một chút chậm trễ trong ecosystem để hỗ trợ spec mới nhất.

Tuyệt vời. Cảm ơn Evan đã dành thời gian. Chúc bạn có một phần trình bày tuyệt vời.