OAuth

In 2025, I introduced MCP (Model Context Protocol) at the iThome Taiwan Cloud Summit. At that time, I mentioned that the official team has been continuously revising the authentication protocol to address complex authentication flows. The previous design involved DCR (Dynamic Client Registration), so as expected, on 2025/11/25, a new Authorization mechanism was released. This authentication mechanism is called “Client ID Metadata Documents, abbreviated as CIMD”.

When installing a Model Context Protocol (MCP) server, the most challenging part is often not the protocol itself, but how to establish trust between the client and server. If you’ve ever tried to connect an MCP client to an MCP server it has never encountered before, you’ve probably run into what’s known as the “registration wall”.

Pre-registering with every possible authorization server is simply not scalable, and while Dynamic Client Registration (DCR) helps, it lacks reliable mechanisms to verify client identity, making it vulnerable to phishing attacks. Beyond security concerns, DCR also creates operational overhead by generating an ever-growing number of duplicate client identities that need to be managed.

2025 年在 iThome 臺灣雲端大會介紹過 MCP (Model Context Protocol)，那時候就有提到在認證協議部分，官方其實一直都在改版解決複雜的認證流程，之前設計的 DCR (Dynamic Client Registration)，所以沒意外去年 2025/11/25 又推出一版 Authorization 機制，此認證機制取名叫『Client ID Metadata Documents 簡稱 CIMD』。

安裝 Model Context Protocol（MCP）伺服器時，最棘手的部分往往不是協議本身，而是如何讓客戶端與伺服器彼此建立信任。如果你曾嘗試讓一個 MCP 客戶端連線到一個從未接觸過的 MCP 伺服器，你大概遇過所謂的「註冊高牆（registration wall）」。

要預先在每一個可能的授權伺服器完成註冊根本無法擴展，而 Dynamic Client Registration（DCR）雖然有所幫助，但因為缺乏可靠的機制來驗證客戶端身份，所以容易遭受網路釣魚攻擊。除了安全性問題之外，DCR 還會造成營運負擔，因為它會產生越來越多需要管理的重複客戶端身份。