接下來我們要來介紹兩種不同傳輸層的服務用的 authrozation 規範為何

先說結論:

• STDIO：使用 環境變數 的方式，最常見的是 Token / API Key。
• Streamlined HTTP：使用 OAuth 2.x 系列協議。

差異:

• STDIO: MCP Server 在本機運行，本身不一定需要授權。只有當它需要與外部服務互動時（例如向 GitLab 發起 Merge Request），才需要。token/key 通常透過環境變數傳入。
• HTTP: 因為透過網路傳輸，安全需求更高
  • 核心價值： OAuth 2.x 允許在**不直接暴露使用者憑證（如帳號密碼）**的情況下，授權 MCP Server 代為執行操作（例如 請 GitLab MCP Server 幫你建立 Merge Request）。
  • 安全優勢： 這能讓 MCP Server 在不洩漏我們在目標服務（例如 GitLab）的完整憑證的前提下，獲得有限的授權來與之互動。

stdio

官方: Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment.

• stdio 是在你本機自己跑起來的 mcp server
• 通常不需要授權：若 MCP Server 僅處理本機邏輯，不會對外呼叫 API，就不需要額外認證。
• 需要授權的情境：當 MCP Server 要存取外部服務（例如 GitLab API、Figma API）時，就必須知道使用者的憑證。
• 做法：透過 環境變數 傳入 Token / API Key。這些 token 會事先在目標服務產生，並且可以設定 scope 來限制權限。

舉例來說：

你在 GitLab 裡為自己的帳戶生成了一個 Personal Access Token，並且在該 token 中設定好它允許的權限 (scope) 有哪些，像是允許建立或讀取 merge request。

接著在你的 MCP Server 所在機器上，以環境變數 (或配置檔中指定 env) 的方式把這個 token 傳給 MCP Server。MCP Server 在要呼叫 GitLab API 時，就用這個 token 來作為認證。

而設定的方式就在 mcp server config.json, 我們可以藉由下面這種方式帶入, 至於要帶入什麼、怎麼帶入則因不同 server 而異:

實際案例

GitLab MCP Server

{
  "mcpServers": {
    "gitlab": {
      "command": "npx",
      "args": ["-y", "@zereight/mcp-gitlab"],
      "env": {
        "GITLAB_PERSONAL_ACCESS_TOKEN": "your_gitlab_token",
        "GITLAB_API_URL": "your_gitlab_api_url",
        "GITLAB_PROJECT_ID": "your_project_id", // Optional: default project
        "GITLAB_ALLOWED_PROJECT_IDS": "", // Optional: comma-separated list of allowed project IDs
        "GITLAB_READ_ONLY_MODE": "false",
        "USE_GITLAB_WIKI": "false", // use wiki api?
        "USE_MILESTONE": "false", // use milestone api?
        "USE_PIPELINE": "false" // use pipeline api?
      }
    }
  }
}

figma Mcp server

{
  "mcpServers": {
    "Framelink Figma MCP": {
      "command": "npx",
      "args": ["-y", "figma-developer-mcp", "--figma-api-key=YOUR-KEY", "--stdio"]
    }
  }
}

readme 也有註記可以設為環境變數: Or you can set FIGMA_API_KEY and PORT in the env field.

MCP Server 的 OAuth 2.0 授權方式

與 STDIO 不同，Streamlined HTTP Transport 採用的是 OAuth 2.0 系列協議。
這種方式特別適合 MCP Server 與遠端服務互動時使用，因為它能在 不直接暴露使用者帳號密碼或永久性憑證 的情況下，安全地授權 MCP Server 代替使用者執行操作。

OAuth 範例：授權第三方應用程式

這就像您在玩 PUBG Mobile 時，授權該應用程式在您每次升級段位時，自動分享貼文到 Facebook。

您先授權 PUBG Mobile 應用程式擁有在您 Facebook 頁面發文的權限。

這個授權是透過 OAuth 2.0 機制完成的，因此 PUBG Mobile 無需知道您的 Facebook 帳號和密碼，就能代為發文。

--

這可以獨立拉一篇明天幫大家科普一下 Oauth2.0 跟 Oauth2.1 的基本概念