Ian Chou's Blog

HTTP Authorization Header 深入解析：為什麼一定要加 Bearer？

HTTP Authorization Header 深入解析：為什麼一定要加 Bearer？

這篇文章解答一個常見的架構設計問題：既然 Server 端邏輯可以寫成「只要 Header 裡有東西就當作 Token」，為什麼還需要在 Authorization Header 中加上 Bearer 前綴？這關係到 HTTP 協議標準、安全性設計，以及生態系相容性。

目錄

核心問題

簡單來說，加上 Bearer 這個前綴（Scheme），就像為什麼檔案要有「副檔名」一樣 —— 雖然你把 .jpg 改成 .txt 電腦可能還是打不開，但標準化的命名讓系統知道該「如何解析」這個檔案。

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

以下是為什麼一定要加 Bearer 的幾個核心原因。

HTTP 標準規範 (RFC 7235)

根據 HTTP 標準，Authorization Header 的格式被嚴格定義為：

Authorization: <Authentication-Scheme> <Credentials>
組成部分 說明
Authentication-Scheme 告訴 Server 驗證的方法是什麼（例如：Basic、Bearer、Digest）
Credentials 實際的驗證內容（例如：Token、加密後的帳號密碼）

[!WARNING]
如果你只傳送 Token 而不加前綴，這在技術上違反了 HTTP 語意，標準的 Proxy、Gateway 或防火牆（WAF）可能會認為這是一個畸形封包（Malformed Request）而將其擋下。

區分不同的驗證方式

在同一個 API 系統中，可能會支援多種驗證方式。Bearer 這個字是用來告訴 Server：「這串亂碼是 Token，請去查驗 Token 的有效性。」

如果沒有這個前綴，Server 就無法區分以下情況：

Scheme 用途
Basic 後面接的是 Base64 編碼的 username:password
Bearer 後面接的是 Access Token (如 JWT)
Digest 後面接的是雜湊摘要認證
AWS4-HMAC-SHA256 AWS 的簽章認證
HOBA Origin-Bound Authentication

情境舉例

如果你的 API 同時支援「舊版 API Key」和「新版 JWT」，有了前綴，你的 Router 就可以這樣寫：

const authHeader = c.req.header('Authorization');
const [scheme, credentials] = authHeader?.split(' ') ?? [];

switch (scheme) {
  case 'Basic':
    // → 走帳號密碼驗證邏輯
    return handleBasicAuth(credentials);
  case 'Bearer':
    // → 走 JWT 驗證邏輯
    return handleJWTAuth(credentials);
  default:
    throw new Error('Unsupported authentication scheme');
}

Bearer 的安全性含義（CISSP 觀點）

RFC 6750 定義了 "Bearer Token Usage"。Bearer 這個字本身是有法律/安全意義的術語，意指 「持有者即擁有者」 (Give access to the bearer of this token)。

Bearer Token 的特性

  Bearer Token 就像現金（Cash）                               
                                                              
  ✓ 誰手上拿著這張鈔票，誰就可以花掉它                       
  ✓ 不需要額外的加密簽名來證明「我是這個 Token 的合法擁有者」
                                                              
  對比：DPoP 或 mTLS 需要額外的私鑰證明                        │

如果在 Header 中明確標示 Bearer，就是在宣告：

「這是一個持有者權杖，Server 只要確認 Token 有效就放行，不需挑戰 Client 的私鑰。」

生態系相容性

許多現成的 Library 和 Middleware 都是依照標準寫的。例如在 Node.js / Bun 生態系中，常見的 express-jwt 或 Hono 的 jwt middleware，預設邏輯通常是：

// 偽代碼邏輯
const authHeader = c.req.header('Authorization');
const [scheme, token] = authHeader.split(' ');

if (scheme !== 'Bearer') {
  throw new Error('Invalid Scheme'); // 如果你沒傳 Bearer，這裡直接報錯
}
// 接著驗證 token...

[!IMPORTANT]
如果你不加 Bearer，你就無法直接使用這些標準的開源套件，必須自己造輪子寫解析邏輯。

深入分析各種 Authentication Scheme

理解這些 Scheme 的「適用場景」比理解實作細節更重要。簡單來說：Bearer 是現代應用層開發的主流（Access），而其他 Scheme 通常用於基礎設施層或特殊的安全需求（Integrity/Non-repudiation）。

1. AWS4-HMAC-SHA256 (Signature Schemes)

狀態：極度常用 (Infrastructure Layer)

這可能是除了 Bearer 之外，開發者最常接觸到的，特別是在使用 Cloudflare R2 或 AWS S3 時。

核心目的

不僅驗證「你是誰」，還驗證「請求內容有沒有被竄改」 (Integrity)。

運作原理

它不是傳送一個靜態 Token，而是將「HTTP Method + URI + Timestamp + Body Payload」全部串起來，用 Secret Key 進行雜湊簽章（HMAC）。

與 Bearer 的關鍵差異

─────────────────────────────────────────────────────────────
  Bearer Token vs AWS Signature                               
─────────────────────────────────────────────────────────────
                                                              
  Bearer Token 就像一張「門票」                                
  • 駭客攔截到這張票（且沒過期），可以用這張票存取任何 API       
  • 可能遭受 Replay Attack                                    
                                                              
  AWS Signature 就像「支票」                                   
  • 這張支票上寫死了「付給誰、付多少錢、幾點幾分」              
  • 駭客攔截了這封請求也沒用                                   
  • 無法修改接收方或金額（Payload）                            
  • 無法在幾分鐘後重送（Timestamp 過期）                       
                                                              
─────────────────────────────────────────────────────────────

應用場景

如果你在 Node.js 中使用 AWS SDK 或 S3Client 上傳檔案到 Cloudflare R2，SDK 底層就是在幫你生成這個 Header。但在你的 MCP Server API 設計上，除非有極高的「防竄改」需求，否則手刻這個驗證邏輯會太過複雜。

2. Digest Authentication

狀態：老舊但強韌 (Legacy / IoT / Hardware)

在舊款 IP Camera、路由器或嵌入式設備中可能還會看到這個。

核心目的

在沒有 HTTPS (TLS) 的年代，避免密碼在網路上裸奔。

運作原理

Server 給 Client 一個隨機數 (Nonce)，Client 把 MD5(Username + Password + Nonce) 算出來傳回去。

為什麼現代 Web 不用了？

原因 說明
HTTPS 普及 現在都有 HTTPS 了，通道加密解決了密碼裸奔問題
MD5 不安全 它通常依賴 MD5（已被視為不安全）
資料庫不友善 Server 必須存明碼密碼或特定格式的 Hash 才能驗證

[!NOTE]
除非你的 MCP Server 要去控制一台 10 年前的舊款 Switch 或監視器，否則現代 Web 開發完全不需要考慮它。

3. HOBA (HTTP Origin-Bound Authentication)

狀態：歷史的眼淚 (Evolved into WebAuthn/FIDO2)

核心目的

想要擺脫密碼，改用公私鑰登入，而且要綁定網域（Origin-Bound），防止釣魚網站。

現況

HOBA (RFC 7486) 本身並沒有被廣泛採用。它的精神被 WebAuthn (FIDO2) 和 Passkeys 繼承了。

應用場景

如果你想做「無密碼登入 (Passwordless)」，你不會用 HOBA header，你會使用 WebAuthn API，這通常涉及前端的 navigator.credentials.get() 和後端的驗證邏輯。這時候 Header 通常還是會回歸到 Bearer (JWT)，只是這個 JWT 是透過 FIDO2 驗證後換發的。

4. Basic Authentication

狀態：特殊場景仍在使用

雖然 Basic Auth 看似過時，但在現代開發中還有一個非常重要的「存活場景」：OAuth 2.0 的後端驗證。

當你的 Node.js Server 要去跟 Google 或 GitHub 交換 Token 時（exchange code for token）：

POST /oauth/token
Host: github.com
Authorization: Basic <Base64(ClientId:ClientSecret)>
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=xxx&redirect_uri=yyy

在這個場景下，ClientId 是帳號，ClientSecret 是密碼。因為這是 Server 對 Server 的溝通（通常在安全內網或 TLS 下），所以標準允許使用 Basic Auth 來驗證「應用程式本身的身份」。

Scheme 比較表

從 CISSP 視角分析各種 Authentication Scheme：

Scheme 核心屬性 (CIA) 適用場景 MCP 專案建議
Bearer Confidentiality (依賴 TLS) 現代 REST/GraphQL API ✅ 首選。實作簡單，生態系豐富。
Basic Authentication OAuth 2.0 Client 驗證 ⚠️ 僅用於後端交換 Token，不用於 API 保護。
AWS4-HMAC Integrity + Auth 雲端基礎設施 (S3/R2) ⚠️ 除非涉及高敏感金融交易，否則實作成本過高。
Digest Confidentiality (Legacy) 舊型硬體/IoT ❌ 過時。
WebAuthn Auth + Non-repudiation 生物辨識/無密碼登入 ✅ 可作為取得 Bearer Token 之前的前置驗證手段。

實作建議

對於 MCP SSE Server，建議直接使用 Bearer Scheme 搭配 JWT：

Hono Middleware 範例

import { Hono } from 'hono';
import { jwt } from 'hono/jwt';

const app = new Hono();

// JWT 驗證 Middleware
app.use('/sse/*', jwt({
  secret: process.env.JWT_SECRET!,
}));

// SSE Endpoint
app.get('/sse', async (c) => {
  // 從驗證後的 payload 取得使用者資訊
  const payload = c.get('jwtPayload');
  console.log('Authenticated user:', payload.sub);

  // 建立 SSE 連線
  return streamSSE(c, async (stream) => {
    // ... SSE 邏輯
  });
});

export default app;

流程說明

─────────────────────────────────────────────────────────────
  MCP SSE 認證流程                                            
─────────────────────────────────────────────────────────────
                                                              
  1. Client 連線時帶 Authorization: Bearer <JWT>              
       ↓                                                      
  2. Server (Hono/Express) 的 Middleware 解析 JWT            
       ↓                                                      
  3. 驗證通過後，建立 SSE 連線                                 
       ↓                                                      
  4. 後續 POST /messages 也需要帶相同的 Bearer Token          
                                                              
─────────────────────────────────────────────────────────────

總結

雖然你可以寫程式允許「不加 Bearer」，但加上 Bearer 是為了：

目的 說明
標準合規 遵守 RFC 7235 格式
避免歧義 讓 Server 知道這不是 Basic Auth 或其他簽名
工具相容 讓 Postman、Swagger、Curl 以及現成的 JWT Middleware 能正常運作
安全語意 明確宣告這是「持有者權杖」，不需額外的 challenge

[!TIP]
對於現代 Web 開發和 MCP Server，Bearer Scheme 搭配 JWT 是最符合 Industry Standard 的做法，實作簡單且生態系豐富。

最後更新: 2026-01-10