Resource Indicators

RFC 8707 定義了 OAuth 2.0 的 Resource Indicators 機制，讓 Client 在授權請求中透過 resource 參數明確指定 Token 的目標 Resource Server。

解決什麼問題

一個 Authorization Server 可能同時服務多個 Resource Server。如果核發的 Token 沒有綁定目標，會產生安全風險：

攻擊者取得 Server A 的 Token 後，可以拿去存取 Server B
Resource Server 無法確認 Token 是不是專門為自己核發的

RFC 8707 透過 resource 參數讓 Token 綁定特定的 audience，收到 Token 的 Resource Server 可以驗證自己是否為 intended audience。

運作方式

Authorization Request

Client 在導向 Authorization Endpoint 時帶上 resource 參數：

GET /authorize?response_type=code
  &client_id=s6BhdRkqt3
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
  &scope=read
  &resource=https%3A%2F%2Fapi.example.com HTTP/1.1
Host: auth.example.com

Token Request

Client 在向 Token Endpoint 交換 Token 時也帶上 resource 參數：

POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
&resource=https%3A%2F%2Fapi.example.com

Authorization Server 處理

AS 收到 resource 參數後：

SHOULD 將 audience 資訊綁定到核發的 Token 中
如果 resource 值無效或不被允許，SHOULD 回傳 invalid_target 錯誤
如果沒有收到 resource 參數，MAY 拒絕請求或使用預設值

各角色的職責

角色	職責	要求等級
Client	在 authorization request 和 token request 中帶上 `resource` 參數	SHOULD
Authorization Server	處理 `resource` 參數，將 audience 綁定到 Token	SHOULD
Resource Server	不需要實作 RFC 8707，但可以驗證 Token 的 audience 是否為自己	—

Resource Server 的 audience 驗證不是 RFC 8707 定義的，而是 Token 驗證的一般實踐（如 JWT 的 aud claim）。

`resource` 參數格式

MUST 是一個絕對 URI
MUST 不包含 fragment（#）
Client SHOULD 提供最具體的 URI 來識別目標 Resource Server

合法的範例：

https://api.example.com
https://api.example.com/v1
https://api.example.com:8443

不合法的範例：

api.example.com（缺少 scheme）
https://api.example.com#section（包含 fragment）

安全考量

Token 受眾驗證

Resource Server 在收到 Token 後，應驗證自己是否為該 Token 的 intended audience。若 Token 使用 JWT 格式，可以透過 aud claim 進行驗證；若為 Opaque Token，則需透過 Token Introspection 取得 audience 資訊。未通過受眾驗證的 Token 應被拒絕，避免跨服務的 Token 盜用。

降級攻擊

如果 Authorization Server 在未收到 resource 參數時仍核發不綁定 audience 的 Token，攻擊者可以故意省略 resource 參數來取得「萬用 Token」。AS 應根據自身的安全策略決定是否拒絕缺少 resource 參數的請求。

在 MCP 中的應用

MCP Authorization 將 RFC 8707 的要求等級提高：Client MUST 在每次請求中帶上 resource 參數，即使 AS 不支援也要送；Server MUST 驗證 Token 的 audience。詳見 MCP Authorization 總覽。