> ## Documentation Index
> Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 信息征集

<div id="enable-section-numbers" />

模型上下文协议（MCP）为服务器提供了一种标准化方式，使其能够在交互过程中通过客户端向用户请求额外信息。此流程使客户端能够在保持对用户交互和数据共享控制的同时，让服务器动态地收集所需信息。

信息征集支持两种模式：

* **表单模式**：服务器可以使用可选的 JSON Schema 向用户请求结构化数据以验证响应
* **URL 模式**：服务器可以将用户引导至外部 URL 进行敏感交互，这些交互 *不得* 通过 MCP 客户端传递

## 用户交互模型

MCP 中的信息征集允许服务器通过启用用户输入请求 *嵌套* 在其他 MCP 服务器功能内来实现交互式工作流。

实现可以自由暴露信息征集通过任何适合其需求的界面模式——协议本身不强制任何特定的用户交互模型。

<Warning>
  为了信任、安全和安全性：

  * 服务器 **不得** 使用表单模式信息征集来请求敏感信息，例如密码、API 密钥、访问令牌或支付凭证
  * 服务器 **必须** 使用 [URL 模式](#url-mode-elicitation-requests) 进行涉及此类敏感信息的交互

  此上下文中的“敏感信息”指的是授予访问权限或授权交易的秘密和凭证。一般联系或个人资料信息（例如姓名、电子邮件地址或用户名）并非明确禁止；是否通过表单模式请求此类数据由服务器自行决定，并取决于用户审查和拒绝的能力。

  MCP 客户端 **必须**：

  * 提供 UI 以明确哪个服务器正在请求信息
  * 尊重用户隐私并提供明确的拒绝和取消选项
  * 对于表单模式，允许用户在发送前审查和修改其响应
  * 对于 URL 模式，清晰显示目标域名/主机并在导航到目标 URL 之前获取用户同意
</Warning>

## 能力

支持信息征集的客户端 **必须** 在每次请求中于 `_meta.io.modelcontextprotocol/clientCapabilities` 声明 `elicitation` 能力：

```json theme={null}
{
  "_meta": {
    "io.modelcontextprotocol/clientCapabilities": {
      "elicitation": {
        "form": {},
        "url": {}
      }
    }
  }
}
```

为了向后兼容，空能力对象等同于仅声明支持 `form` 模式：

```jsonc theme={null}
{
  "_meta": {
    "io.modelcontextprotocol/clientCapabilities": {
      "elicitation": {}, // 等同于 { "form": {} }
    },
  },
}
```

声明 `elicitation` 能力的客户端 **必须** 支持至少一种模式（`form` 或 `url`）。

服务器 **不得** 发送客户端不支持的模式的信息征集请求。

## 协议消息

### 信息征集请求

服务器 **可以** 在处理客户端请求期间，通过发送包含 `elicitation/create` 请求的 [`InputRequiredResult`](/specification/draft/basic/patterns/mrtr#inputrequiredresult) 来向用户请求信息。

所有信息征集请求 **必须** 包含以下参数：

| 名称        | 类型     | 选项            | 描述                                    |
| --------- | ------ | ------------- | ------------------------------------- |
| `mode`    | string | `form`, `url` | 信息征集的模式。对于表单模式为可选（如果省略则默认为 `"form"`）。 |
| `message` | string |               | 人类可读的消息，解释为什么需要此交互。                   |

`mode` 参数指定信息征集的类型：

* `"form"`：带内结构化数据收集，带有可选的 Schema 验证。数据暴露给客户端。
* `"url"`：通过 URL 导航的带外交互。数据（URL 本身除外） **不** 暴露给客户端。

为了向后兼容，服务器 **可以** 省略表单模式信息征集请求的 `mode` 字段。客户端 **必须** 将没有 `mode` 字段的请求视为表单模式。

### 表单模式信息征集请求

表单模式信息征集允许服务器通过 MCP 客户端直接收集结构化数据。

表单模式信息征集请求 **必须** 指定 `mode: "form"` 或省略 `mode` 字段，并包含这些附加参数：

| 名称                | 类型     | 描述                     |
| ----------------- | ------ | ---------------------- |
| `requestedSchema` | object | 定义预期响应结构的 JSON Schema。 |

#### 请求的 Schema

`requestedSchema` 参数允许服务器使用 JSON Schema 的受限子集来定义预期响应的结构。

为了简化客户端用户体验，表单模式信息征集 Schema 仅限于具有原始属性的扁平对象。

Schema 仅限于这些原始类型：

1. **字符串 Schema**

   ```json theme={null}
   {
     "type": "string",
     "title": "显示名称",
     "description": "描述文本",
     "minLength": 3,
     "maxLength": 50,
     "format": "email",
     "default": "user@example.com"
   }
   ```

   支持的格式：`email`, `uri`, `date`, `date-time`

2. **数字 Schema**

   ```json theme={null}
   {
     "type": "number", // 或 "integer"
     "title": "显示名称",
     "description": "描述文本",
     "minimum": 0,
     "maximum": 100,
     "default": 50
   }
   ```

3. **布尔值 Schema**

   ```json theme={null}
   {
     "type": "boolean",
     "title": "显示名称",
     "description": "描述文本",
     "default": false
   }
   ```

4. **枚举 Schema**

   单选枚举（无标题）：

   ```json theme={null}
   {
     "type": "string",
     "title": "颜色选择",
     "description": "选择您最喜欢的颜色",
     "enum": ["Red", "Green", "Blue"],
     "default": "Red"
   }
   ```

   单选枚举（带标题）：

   ```json theme={null}
   {
     "type": "string",
     "title": "颜色选择",
     "description": "选择您最喜欢的颜色",
     "oneOf": [
       { "const": "#FF0000", "title": "红色" },
       { "const": "#00FF00", "title": "绿色" },
       { "const": "#0000FF", "title": "蓝色" }
     ],
     "default": "#FF0000"
   }
   ```

   多选枚举（无标题）：

   ```json theme={null}
   {
     "type": "array",
     "title": "颜色选择",
     "description": "选择您最喜欢的颜色",
     "minItems": 1,
     "maxItems": 2,
     "items": {
       "type": "string",
       "enum": ["Red", "Green", "Blue"]
     },
     "default": ["Red", "Green"]
   }
   ```

   多选枚举（带标题）：

   ```json theme={null}
   {
     "type": "array",
     "title": "颜色选择",
     "description": "选择您最喜欢的颜色",
     "minItems": 1,
     "maxItems": 2,
     "items": {
       "anyOf": [
         { "const": "#FF0000", "title": "红色" },
         { "const": "#00FF00", "title": "绿色" },
         { "const": "#0000FF", "title": "蓝色" }
       ]
     },
     "default": ["#FF0000", "#00FF00"]
   }
   ```

客户端可以使用此 Schema 来：

1. 生成适当的输入表单
2. 在发送前验证用户输入
3. 为用户提供更好的指导

所有原始类型都支持可选的默认值以提供合理的起点。支持默认值的客户端 **应** 使用这些值预填充表单字段。

请注意，复杂的嵌套结构、对象数组（枚举除外）和其他高级 JSON Schema 功能故意不支持，以简化客户端用户体验。

#### 示例：简单文本请求

**Input request (delivered inside [`InputRequiredResult.inputRequests`](/specification/draft/basic/patterns/mrtr#inputrequests)):**

```json theme={null}
{
  "method": "elicitation/create",
  "params": {
    "mode": "form",
    "message": "请提供您的 GitHub 用户名",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string"
        }
      },
      "required": ["name"]
    }
  }
}
```

**Client result (returned inside `inputResponses` on the retried request):**

```json theme={null}
{
  "action": "accept",
  "content": {
    "name": "octocat"
  }
}
```

#### 示例：结构化数据请求

**Input request (delivered inside `InputRequiredResult.inputRequests`):**

```json theme={null}
{
  "method": "elicitation/create",
  "params": {
    "mode": "form",
    "message": "请提供您的联系信息",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string",
          "description": "您的全名"
        },
        "email": {
          "type": "string",
          "format": "email",
          "description": "您的电子邮件地址"
        },
        "age": {
          "type": "number",
          "minimum": 18,
          "description": "您的年龄"
        }
      },
      "required": ["name", "email"]
    }
  }
}
```

**Client result (returned inside `inputResponses` on the retried request):**

```json theme={null}
{
  "action": "accept",
  "content": {
    "name": "Monalisa Octocat",
    "email": "octocat@github.com",
    "age": 30
  }
}
```

### URL 模式信息征集请求

<Note>
  **新功能：** URL 模式信息征集是在 `2025-11-25` 版本的 MCP 规范中引入的。其设计和实现可能会在未来的协议修订中更改。
</Note>

URL 模式信息征集使服务器能够将用户引导至外部 URL 进行不得通过 MCP 客户端传递的带外交互。这对于认证流程、支付处理以及其他敏感或安全操作至关重要。

URL 模式信息征集请求 **必须** 指定 `mode: "url"`，`message`，并包含这些附加参数：

| Name  | Type   | Description  |
| ----- | ------ | ------------ |
| `url` | string | 用户应导航到的 URL。 |

`url` 参数 **必须** 包含有效的 URL。

<Note>
  **重要**：URL 模式信息征集 *不是* 用于授权 MCP 客户端访问 MCP 服务器（那由 [MCP 授权](../basic/authorization) 处理）。相反，当 MCP 服务器需要代表用户获取敏感信息或第三方授权时使用它。客户端的持有者令牌保持不变。客户端的唯一责任是为用户提供关于服务器希望他们打开的信息征集 URL 的上下文。
</Note>

#### 示例：请求敏感数据

此示例显示了一个 URL 模式信息征集请求，将用户引导至一个安全 URL，他们可以在那里提供敏感信息（例如 API 密钥）。
相同的请求可以将用户引导至 OAuth 授权流程或支付流程。唯一的区别是 URL 和消息。

**Input request (delivered inside `InputRequiredResult.inputRequests`):**

```json theme={null}
{
  "method": "elicitation/create",
  "params": {
    "mode": "url",
    "url": "https://mcp.example.com/ui/set_api_key",
    "message": "请提供您的 API 密钥以继续。"
  }
}
```

**Client result (returned inside `inputResponses` on the retried request):**

```json theme={null}
{
  "action": "accept"
}
```

`action: "accept"` 的响应表示用户已同意该交互。这并不意味着交互已完成。交互在带外进行，客户端不会直接获知结果。当客户端重试原始请求时，服务器会根据回显的 `requestState`（或其自身存储的状态）判断带外交互是否已完成，并返回最终结果或再次响应 `InputRequiredResult`。客户端 **应** 提供手动控件，让用户重试或取消原始请求（或以其他方式恢复与客户端的交互）。

## 消息流程

### 表单模式流程

```mermaid theme={null}
sequenceDiagram
    participant User as 用户
    participant Client as 客户端
    participant Server as 服务器

    Client->>Server: tools/call(id: 1)
    note over Server: 服务器需要更多信息
    Server-->>Client: InputRequiredResult(elicitation/create (mode: form))

    Note over User,Client: 展示信息收集界面
    User-->>Client: 提供请求的信息

    Note over Server,Client: 使用新信息重试请求
    Client->>Server: tools/call(id: 2, user response)
    Server-->>Client: Result(id: 2, result)
```

### URL 模式流程

```mermaid theme={null}
sequenceDiagram
    participant UserAgent as 用户代理 (浏览器)
    participant User as 用户
    participant Client as 客户端
    participant Server as 服务器

    Client->>Server: tools/call(id: 1)
    Note over Server: 服务器需要更多信息 <br/> 服务器创建编码了 url 信息的 requestState。
    Server-->>Client: InputRequiredResult(elicitation/create (mode: url), requestState)

    Client->>User: 展示打开 URL 的同意请求
    User-->>Client: 提供同意

    Client->>UserAgent: 打开 URL
    Client->>Server: tools/call(id: 2, 接受响应, requestState))
    Note over Server: 服务器使用 requestState 发现 url 信息。 <br/> 它可能需要阻塞，直到请求完成。

    Note over User,UserAgent: 用户交互
    UserAgent-->>Server: 交互完成

    Note over Server: 使用新信息继续处理
    Server-->Client: Result(id: 2, result)
```

## 响应操作

信息收集响应使用三操作模型来清楚地区分不同的用户操作。这些操作适用于表单和 URL 信息收集模式。

```json theme={null}
{
  "action": "accept", // 或 "decline" 或 "cancel"
  "content": {
    "propertyName": "value",
    "anotherProperty": 42
  }
}
```

三种响应操作是：

1. **接受** (`action: "accept"`): 用户明确批准并提交数据
   * 对于表单模式：`content` 字段包含与请求模式匹配的提交数据
   * 对于 URL 模式：`content` 字段被省略
   * 示例：用户点击了“提交”、“确定”、“确认”等。

2. **拒绝** (`action: "decline"`): 用户明确拒绝请求
   * `content` 字段通常被省略
   * 示例：用户点击了“拒绝”、“谢绝”、“否”等。

3. **取消** (`action: "cancel"`): 用户解散而未做出明确选择
   * `content` 字段通常被省略
   * 示例：用户关闭了对话框、点击了外部、按了 Escape 键、浏览器加载失败等。

服务器应适当处理每种状态：

* **接受**：处理提交的数据
* **拒绝**：处理明确拒绝（例如，提供替代方案）
* **取消**：处理解散（例如，稍后再次提示）

## 实现注意事项

### 状态性

信息征集不要求服务器通过 [multi round-trip requests](/specification/draft/basic/patterns/mrtr#multi-round-trip-requests) 机制维护关于用户的状态。

然而，如果存储了状态，实现信息征集的服务器 **必须** 按照 [security best practices](/docs/tutorials/security/security_best_practices) 文档中的指南，将此状态与单个用户安全关联。具体而言：

* 状态存储 **必须** 防止未经授权的访问
* 对于远程 MCP 服务器，用户身份 **必须** 尽可能从通过 [MCP 授权](../basic/authorization) 获取的凭证中派生（例如 `sub` 声明）

<Note>
  本节中的示例是非规范性的，并说明了信息收集的潜在用途。
  实现者应在保持安全最佳实践的同时，将这些模式适应其特定需求。
</Note>

### 用于敏感数据的 URL 模式信息收集

对于与需要敏感信息的外部 API 交互的服务器（例如，凭证、支付信息），URL 模式信息收集提供了一种安全机制，让用户提供此信息而不将其暴露给 MCP 客户端。

在此模式中：

1. 服务器将用户引导至安全网页（通过 HTTPS 服务）
2. 页面在用户信任的域上展示品牌化的表单界面
3. 用户直接将敏感凭证输入到安全表单中
4. 服务器安全地存储凭证，绑定到用户身份
5. 后续的 MCP 请求使用这些存储的凭证进行 API 访问

这种方法确保敏感凭证永远不会通过 LLM 上下文、MCP 客户端或任何中间 MCP 服务器，减少通过客户端日志记录或其他攻击向量暴露的风险。

### 用于 OAuth 流程的 URL 模式信息收集

URL 模式信息收集启用了一种模式，其中 MCP 服务器充当第三方资源服务器的 OAuth 客户端。
通过 URL 模式信息收集启用的外部 API 授权与 [MCP 授权](../basic/authorization) 是分开的。MCP 服务器 **不得** 依赖 URL 模式信息收集来为用户授权自身。

#### 理解区别

* **MCP 授权**：MCP 客户端和 MCP 服务器之间所需的 OAuth 流程（在 [授权规范](../basic/authorization) 中涵盖）
* **外部（第三方）授权**：MCP 服务器和第三方资源服务器之间的可选授权，通过 URL 模式信息收集发起

在外部授权中，服务器同时充当：

* OAuth 资源服务器（对于 MCP 客户端）
* OAuth 客户端（对于第三方资源服务器）

示例场景：

* MCP 客户端连接到 MCP 服务器
* MCP 服务器集成各种不同的第三方服务
* 当 MCP 客户端调用需要访问第三方服务的工具时，MCP 服务器需要该服务的凭证

关键安全要求是：

1. **第三方凭证不得通过 MCP 客户端传输**：客户端绝不能看到第三方凭证以保护安全边界
2. **MCP 服务器不得将客户端的凭证用于第三方服务**：那将是 [令牌透传](/docs/tutorials/security/security_best_practices#token-passthrough)，这是禁止的
3. **用户必须直接授权 MCP 服务器**：交互发生在 MCP 协议之外，不涉及 MCP 客户端
4. **MCP 服务器负责令牌**：MCP 服务器负责存储和管理通过 URL 模式信息征集获得的第三方令牌（换句话说，MCP 服务器必须是有状态的）。

通过 URL 模式信息征集获得的凭证不同于 MCP 客户端使用的 MCP 服务器凭证。MCP 服务器 **不得** 将通过 URL 模式信息征集获得的凭证传输给 MCP 客户端。

<Note>
  有关更多背景信息，请参阅安全最佳实践文档的 [令牌透传
  部分](/docs/tutorials/security/security_best_practices#token-passthrough)
  以了解为什么 MCP 服务器不能充当透传代理。
</Note>

#### 实现模式

当通过 URL 模式信息征集实现外部授权时：

1. MCP 服务器生成一个授权 URL，充当第三方服务的 OAuth 客户端
2. MCP 服务器存储内部状态，将 elicitation 请求与用户身份关联（绑定）
3. MCP 服务器向客户端发送一个 URL 模式 elicitation 请求，其中包含可启动授权流程的 URL，以及一个可选的 `requestState`，用于编码关于 elicitation 请求和用户的信息（如有需要）
4. 用户直接与第三方授权服务器完成 OAuth 流程
5. 第三方授权服务器重定向回 MCP 服务器
6. MCP 服务器安全地存储第三方令牌，并将其绑定到用户身份
7. 未来的 MCP 请求可以利用这些已存储的令牌访问第三方资源服务器

以下是如何实现此模式的非规范性示例：

```mermaid theme={null}
sequenceDiagram
    participant User as 用户
    participant UserAgent as 用户代理 (浏览器)
    participant 3AS as 第三方 AS
    participant 3RS as 第三方 RS
    participant Client as MCP 客户端
    participant Server as MCP 服务器

    Client->>Server: tools/call
    Note over Server: 需要为用户进行第三方授权
    Note over Server: 存储状态（将 elicitation 请求绑定到用户）
    Note over Server: 生成编码原始请求和用户信息的 requestState
    Server->>Client: InputRequiredResult<br/>(mode: "url", url: "https://mcp.example.com/connect?...", requestState)

    Client->>User: 展示打开 URL 的同意请求
    User->>Client: 提供同意
    Client->>UserAgent: 打开 URL
    Client->>Server: 接受响应
    UserAgent->>Server: 加载 connect 路由

    Note over Server: 确认：用户已登录 MCP Server 或 MCP AS<br>确认：elicitation 用户与会话用户匹配
    Server->>UserAgent: 重定向到第三方授权端点
    UserAgent->>3AS: 加载 authorize 路由
    Note over 3AS,User: 用户交互（OAuth 流程）：<br>用户同意 MCP Server 的作用域访问
    3AS->>UserAgent: 重定向到 MCP Server 的 redirect_uri
    UserAgent->>Server: 加载 redirect_uri 页面
    Note over Server: 确认：redirect_uri 属于 MCP Server
    Server->>3AS: 将授权码交换为 OAuth 令牌
    3AS->>Server: 授予令牌
    Note over Server: 将令牌绑定到 MCP 用户身份
    Client->>Server: tools/call (ElicitResults, requestState)
    Note over Server: 检索绑定到用户身份的令牌
    Server->>3RS: 调用第三方 API
```

此模式在保持清晰安全边界的同时，启用了与需要用户授权的第三方服务的丰富集成。

## 错误处理

Servers **SHOULD NOT** 假设 elicitation 请求总是会成功，并且 **MUST** 处理用户拒绝或取消 elicitation，或客户端无法处理请求的情况。

## 安全考虑

1. Servers **MUST** 将 elicitation 请求绑定到客户端和用户身份
2. Clients **MUST** 明确指示哪个服务器正在请求信息
3. Clients **SHOULD** 实现用户批准控制
4. Clients **SHOULD** 允许用户随时拒绝 elicitation 请求
5. Clients **SHOULD** 以清楚说明所请求信息及其原因的方式呈现 elicitation 请求

### 安全 URL 处理

请求诱导的 MCP 服务器：

1. **MUST NOT** 在发送给客户端的 URL elicitation 请求中的 URL 里包含关于最终用户的敏感信息，包括凭证、个人可识别信息等。
2. **MUST NOT** 提供一个已预先认证、可访问受保护资源的 URL，因为恶意客户端可能使用该 URL 冒充用户。
3. **SHOULD NOT** 在表单模式 elicitation 请求的任何字段中包含旨在可点击的 URL。
4. **SHOULD** 在非开发环境中使用 HTTPS URL。

这些服务器要求确保客户端实现有关于何时向用户展示 URL 的明确规则，以便一致地应用客户端规则（如下所述）。

实现 URL 模式诱导的客户端 **必须** 小心处理 URL，以防止用户在不知情的情况下点击恶意链接。

处理 URL 模式诱导请求时，MCP 客户端：

1. **不得** 自动预取 URL 或其任何元数据。
2. **不得** 在未经用户明确同意的情况下打开 URL。
3. **必须** 在同意前向用户显示完整 URL 以供检查。
4. **必须** 以安全的方式打开服务器提供的 URL，使得客户端或 LLM 无法检查内容或用户输入。
   例如，在 iOS 上，[SFSafariViewController](https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller) 是合适的，但 [WkWebView](https://developer.apple.com/documentation/webkit/wkwebview) 不合适。
5. **应当** 突出显示 URL 的域名以减轻子域名欺骗。
6. **应当** 对模糊/可疑的 URI（即包含 Punycode 的）发出警告。
7. **不应当** 在诱导请求的任何字段中将 URL 渲染为可点击，除非是 URL 诱导请求中的 `url` 字段（受上述限制约束）。

### 识别用户

服务器 **不得** 依赖未经服务器验证的客户端提供的用户身份识别，因为这可能被伪造。
相反，服务器 **应当** 遵循 [安全最佳实践](/docs/tutorials/security/security_best_practices)。

非规范性示例：

* 错误：将用户输入（如 "I am [joe@example.com](mailto:joe@example.com)"）视为权威
* 正确：依赖 [授权](../basic/authorization) 来识别用户

### 表单模式安全

1. 服务器 **不得** 通过表单模式请求敏感信息（密码、API 密钥等）
2. 客户端 **应当** 针对提供的模式验证所有响应
3. 服务器 **应当** 验证接收到的数据是否符合请求的模式

#### 网络钓鱼

URL 模式诱导返回一个攻击者可用于发送给受害者的 URL。MCP 服务器 **必须** 在接受信息之前验证打开 URL 的用户身份。

通常身份验证是通过利用 [MCP 授权服务器](../basic/authorization) 来识别用户，通过浏览器中的会话 cookie 或等效机制完成。

例如，URL 模式诱导可用于执行 OAuth 流程，其中服务器充当另一个资源服务器的 OAuth 客户端。如果没有适当的缓解措施，可能发生以下网络钓鱼攻击：

1. 连接到良性服务器的恶意用户（Alice）触发诱导请求
2. 良性服务器生成授权 URL，充当第三方授权服务器的 OAuth 客户端
3. Alice 的客户端显示 URL 并请求同意
4. Alice 没有点击链接，而是诱骗同一良性服务器的受害用户（Bob）点击它
5. Bob 打开链接并完成授权，认为他们正在授权自己与良性服务器的连接
6. 良性服务器收到来自第三方授权服务器的回调/重定向，并假设这是 Alice 的请求
7. 第三方服务器的令牌绑定到 Alice 的会话和身份，而不是 Bob 的，导致账户接管

为了防止此攻击，服务器 **必须** 确保启动诱导请求的用户（通过 MCP 客户端访问服务器的最终用户）与完成授权流程的用户是同一人。

有很多方法可以实现这一点，最佳方法将取决于具体实现。

As a common, non-normative example, consider a case where the MCP server is accessible via the web and desires to perform a third-party authorization code flow.
To prevent the phishing attack, the server would create a URL mode elicitation to `https://mcp.example.com/connect?...` rather than the third-party authorization endpoint.
This "connect URL" must ensure the user who opened the page is the same user for whom the elicitation was generated.
It would, for example, check that the user has a valid session cookie and that the session cookie is for the same user who was using the MCP client to generate the URL mode elicitation.
This could be done by comparing the authoritative subject (`sub` claim) from the MCP server's authorization server to the subject from the session cookie.
Once that page ensures the same user, it can send the user to the third-party authorization server at `https://example.com/authorize?...` where a normal OAuth flow can be completed.

在其他情况下，服务器可能无法通过 Web 访问，也可能无法使用会话 cookie 来识别用户。
在这种情况下，服务器必须使用不同的机制来识别打开 elicitation URL 的用户与生成该 elicitation 的用户是同一人。

在所有实现中，服务器 **必须** 确保确定用户身份的机制能够抵御攻击者可以修改诱导 URL 的攻击。