.NET Web 安全试题 01：OAuth 2.0、OIDC 与职责边界
001 关于OAuth 2.0，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 拿到 access token 就能证明用户身份和登录时间
- B. OAuth 2.0 定义授权委托框架，使客户端在限定范围内访问资源
- C. 它本身不规定用户身份登录声明，应结合 OIDC 等身份协议
- D. 只要观察到“API 把授权令牌直接当登录会话”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案B
正确项给出了OAuth 2.0可直接依赖的规则：“OAuth 2.0 定义授权委托框架，使客户端在限定范围内访问资源”。“它本身不规定用户身份登录声明，应结合 OIDC 等身份协议”是应用规则前必须确认的边界，不是规则本身；“拿到 access token 就能证明用户身份和登录时间”则把常见现象或实现细节扩大成了平台保证。场景“API 把授权令牌直接当登录会话”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
002 生产环境出现“API 把授权令牌直接当登录会话”时，针对OAuth 2.0应如何排查？
难度： 进阶
- A. 先验证“它本身不规定用户身份登录声明，应结合 OIDC 等身份协议”，再使用运行时指标、日志或最小复现检查“OAuth 2.0 定义授权委托框架，使客户端在限定范围内访问资源”是否成立。
- B. 直接采用“拿到 access token 就能证明用户身份和登录时间”解释现象，不再收集目标进程和发布配置证据。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“它本身不规定用户身份登录声明，应结合 OIDC 等身份协议”的验证。
- D. 只检查代码是否能够编译，通过后便认定“OAuth 2.0 定义授权委托框架，使客户端在限定范围内访问资源”在当前部署中必然成立。
查看答案与解析
正确答案A
“API 把授权令牌直接当登录会话”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“它本身不规定用户身份登录声明，应结合 OIDC 等身份协议”，再以“OAuth 2.0 定义授权委托框架，使客户端在限定范围内访问资源”组织证据。采用误区“拿到 access token 就能证明用户身份和登录时间”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
003 评审OAuth 2.0相关实现时，以下哪项判断不成立？
难度： 实战
- A. OAuth 2.0 定义授权委托框架，使客户端在限定范围内访问资源
- B. 它本身不规定用户身份登录声明，应结合 OIDC 等身份协议
- C. 拿到 access token 就能证明用户身份和登录时间
- D. 遇到“API 把授权令牌直接当登录会话”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案C
题目要求找出不成立的判断，“拿到 access token 就能证明用户身份和登录时间”正是OAuth 2.0的典型误区。主规则“OAuth 2.0 定义授权委托框架，使客户端在限定范围内访问资源”描述了实现应依赖的契约，边界“它本身不规定用户身份登录声明，应结合 OIDC 等身份协议”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
004 准备上线涉及OAuth 2.0的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“拿到 access token 就能证明用户身份和登录时间”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“OAuth 2.0 定义授权委托框架，使客户端在限定范围内访问资源”修改代码，但不核对“它本身不规定用户身份登录声明，应结合 OIDC 等身份协议”或目标发布模式。
- C. 只验证“它本身不规定用户身份登录声明，应结合 OIDC 等身份协议”，实现仍继续依赖“拿到 access token 就能证明用户身份和登录时间”这一未经证明的假设。
- D. 依据“OAuth 2.0 定义授权委托框架，使客户端在限定范围内访问资源”实现，在“它本身不规定用户身份登录声明，应结合 OIDC 等身份协议”成立的环境中验证，并为“API 把授权令牌直接当登录会话”保留可观测证据和回退条件。
查看答案与解析
正确答案D
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“OAuth 2.0 定义授权委托框架，使客户端在限定范围内访问资源”，部署环境满足“它本身不规定用户身份登录声明，应结合 OIDC 等身份协议”，并能在“API 把授权令牌直接当登录会话”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
005 关于OpenID Connect，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. ID token 与 access token 可在所有端点互换使用
- B. ID token 的受众是客户端，不应直接当作任意 API 的访问令牌
- C. OIDC 在 OAuth 2.0 之上定义身份层，通过 ID token 和 UserInfo 等表达认证结果
- D. 只要观察到“API 接受面向前端客户端的 ID token”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案C
正确项给出了OpenID Connect可直接依赖的规则：“OIDC 在 OAuth 2.0 之上定义身份层，通过 ID token 和 UserInfo 等表达认证结果”。“ID token 的受众是客户端，不应直接当作任意 API 的访问令牌”是应用规则前必须确认的边界，不是规则本身；“ID token 与 access token 可在所有端点互换使用”则把常见现象或实现细节扩大成了平台保证。场景“API 接受面向前端客户端的 ID token”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
006 生产环境出现“API 接受面向前端客户端的 ID token”时，针对OpenID Connect应如何排查？
难度： 进阶
- A. 先验证“ID token 的受众是客户端，不应直接当作任意 API 的访问令牌”，再使用运行时指标、日志或最小复现检查“OIDC 在 OAuth 2.0 之上定义身份层，通过 ID token 和 UserInfo 等表达认证结果”是否成立。
- B. 直接采用“ID token 与 access token 可在所有端点互换使用”解释现象，不再收集目标进程和发布配置证据。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“ID token 的受众是客户端，不应直接当作任意 API 的访问令牌”的验证。
- D. 只检查代码是否能够编译，通过后便认定“OIDC 在 OAuth 2.0 之上定义身份层，通过 ID token 和 UserInfo 等表达认证结果”在当前部署中必然成立。
查看答案与解析
正确答案A
“API 接受面向前端客户端的 ID token”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“ID token 的受众是客户端，不应直接当作任意 API 的访问令牌”，再以“OIDC 在 OAuth 2.0 之上定义身份层，通过 ID token 和 UserInfo 等表达认证结果”组织证据。采用误区“ID token 与 access token 可在所有端点互换使用”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
007 评审OpenID Connect相关实现时，以下哪项判断不成立？
难度： 实战
- A. OIDC 在 OAuth 2.0 之上定义身份层，通过 ID token 和 UserInfo 等表达认证结果
- B. ID token 的受众是客户端，不应直接当作任意 API 的访问令牌
- C. 遇到“API 接受面向前端客户端的 ID token”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
- D. ID token 与 access token 可在所有端点互换使用
查看答案与解析
正确答案D
题目要求找出不成立的判断，“ID token 与 access token 可在所有端点互换使用”正是OpenID Connect的典型误区。主规则“OIDC 在 OAuth 2.0 之上定义身份层，通过 ID token 和 UserInfo 等表达认证结果”描述了实现应依赖的契约，边界“ID token 的受众是客户端，不应直接当作任意 API 的访问令牌”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
008 准备上线涉及OpenID Connect的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“ID token 与 access token 可在所有端点互换使用”完成修改，只要本地运行一次成功就立即发布。
- B. 依据“OIDC 在 OAuth 2.0 之上定义身份层，通过 ID token 和 UserInfo 等表达认证结果”实现，在“ID token 的受众是客户端，不应直接当作任意 API 的访问令牌”成立的环境中验证，并为“API 接受面向前端客户端的 ID token”保留可观测证据和回退条件。
- C. 按照“OIDC 在 OAuth 2.0 之上定义身份层，通过 ID token 和 UserInfo 等表达认证结果”修改代码，但不核对“ID token 的受众是客户端，不应直接当作任意 API 的访问令牌”或目标发布模式。
- D. 只验证“ID token 的受众是客户端，不应直接当作任意 API 的访问令牌”，实现仍继续依赖“ID token 与 access token 可在所有端点互换使用”这一未经证明的假设。
查看答案与解析
正确答案B
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“OIDC 在 OAuth 2.0 之上定义身份层，通过 ID token 和 UserInfo 等表达认证结果”，部署环境满足“ID token 的受众是客户端，不应直接当作任意 API 的访问令牌”，并能在“API 接受面向前端客户端的 ID token”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
009 关于授权服务器，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 资源 API 只要能解析 JWT 就可以自行给任意用户签发令牌
- B. 部署上可由同一产品承担，但信任职责仍需区分
- C. 只要观察到“多个 API 对令牌信任配置不一致”，就能把这次现象视为所有环境中的固定行为。
- D. 授权服务器负责认证主体、获取授权并签发令牌，资源服务器负责验证访问令牌和权限
查看答案与解析
正确答案D
正确项给出了授权服务器可直接依赖的规则：“授权服务器负责认证主体、获取授权并签发令牌，资源服务器负责验证访问令牌和权限”。“部署上可由同一产品承担，但信任职责仍需区分”是应用规则前必须确认的边界，不是规则本身；“资源 API 只要能解析 JWT 就可以自行给任意用户签发令牌”则把常见现象或实现细节扩大成了平台保证。场景“多个 API 对令牌信任配置不一致”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
010 生产环境出现“多个 API 对令牌信任配置不一致”时，针对授权服务器应如何排查？
难度： 进阶
- A. 直接采用“资源 API 只要能解析 JWT 就可以自行给任意用户签发令牌”解释现象，不再收集目标进程和发布配置证据。
- B. 先验证“部署上可由同一产品承担，但信任职责仍需区分”，再使用运行时指标、日志或最小复现检查“授权服务器负责认证主体、获取授权并签发令牌，资源服务器负责验证访问令牌和权限”是否成立。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“部署上可由同一产品承担，但信任职责仍需区分”的验证。
- D. 只检查代码是否能够编译，通过后便认定“授权服务器负责认证主体、获取授权并签发令牌，资源服务器负责验证访问令牌和权限”在当前部署中必然成立。
查看答案与解析
正确答案B
“多个 API 对令牌信任配置不一致”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“部署上可由同一产品承担，但信任职责仍需区分”，再以“授权服务器负责认证主体、获取授权并签发令牌，资源服务器负责验证访问令牌和权限”组织证据。采用误区“资源 API 只要能解析 JWT 就可以自行给任意用户签发令牌”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
011 评审授权服务器相关实现时，以下哪项判断不成立？
难度： 实战
- A. 资源 API 只要能解析 JWT 就可以自行给任意用户签发令牌
- B. 授权服务器负责认证主体、获取授权并签发令牌，资源服务器负责验证访问令牌和权限
- C. 部署上可由同一产品承担，但信任职责仍需区分
- D. 遇到“多个 API 对令牌信任配置不一致”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案A
题目要求找出不成立的判断，“资源 API 只要能解析 JWT 就可以自行给任意用户签发令牌”正是授权服务器的典型误区。主规则“授权服务器负责认证主体、获取授权并签发令牌，资源服务器负责验证访问令牌和权限”描述了实现应依赖的契约，边界“部署上可由同一产品承担，但信任职责仍需区分”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
012 准备上线涉及授权服务器的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“资源 API 只要能解析 JWT 就可以自行给任意用户签发令牌”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“授权服务器负责认证主体、获取授权并签发令牌，资源服务器负责验证访问令牌和权限”修改代码，但不核对“部署上可由同一产品承担，但信任职责仍需区分”或目标发布模式。
- C. 依据“授权服务器负责认证主体、获取授权并签发令牌，资源服务器负责验证访问令牌和权限”实现，在“部署上可由同一产品承担，但信任职责仍需区分”成立的环境中验证，并为“多个 API 对令牌信任配置不一致”保留可观测证据和回退条件。
- D. 只验证“部署上可由同一产品承担，但信任职责仍需区分”，实现仍继续依赖“资源 API 只要能解析 JWT 就可以自行给任意用户签发令牌”这一未经证明的假设。
查看答案与解析
正确答案C
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“授权服务器负责认证主体、获取授权并签发令牌，资源服务器负责验证访问令牌和权限”，部署环境满足“部署上可由同一产品承担，但信任职责仍需区分”，并能在“多个 API 对令牌信任配置不一致”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
013 关于scope 与 audience，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. scope 表达获准操作范围，audience 表达令牌预期资源，两者共同参与 API 授权判断
- B. 验证 scope 后可以跳过 issuer 和 audience 校验
- C. 存在某个 scope 不代表令牌就是签发给当前 API
- D. 只要观察到“另一个 API 的令牌被错误接受”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案A
正确项给出了scope 与 audience可直接依赖的规则：“scope 表达获准操作范围，audience 表达令牌预期资源，两者共同参与 API 授权判断”。“存在某个 scope 不代表令牌就是签发给当前 API”是应用规则前必须确认的边界，不是规则本身；“验证 scope 后可以跳过 issuer 和 audience 校验”则把常见现象或实现细节扩大成了平台保证。场景“另一个 API 的令牌被错误接受”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
014 生产环境出现“另一个 API 的令牌被错误接受”时，针对scope 与 audience应如何排查？
难度： 进阶
- A. 直接采用“验证 scope 后可以跳过 issuer 和 audience 校验”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“存在某个 scope 不代表令牌就是签发给当前 API”的验证。
- C. 先验证“存在某个 scope 不代表令牌就是签发给当前 API”，再使用运行时指标、日志或最小复现检查“scope 表达获准操作范围，audience 表达令牌预期资源，两者共同参与 API 授权判断”是否成立。
- D. 只检查代码是否能够编译，通过后便认定“scope 表达获准操作范围，audience 表达令牌预期资源，两者共同参与 API 授权判断”在当前部署中必然成立。
查看答案与解析
正确答案C
“另一个 API 的令牌被错误接受”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“存在某个 scope 不代表令牌就是签发给当前 API”，再以“scope 表达获准操作范围，audience 表达令牌预期资源，两者共同参与 API 授权判断”组织证据。采用误区“验证 scope 后可以跳过 issuer 和 audience 校验”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
015 评审scope 与 audience相关实现时，以下哪项判断不成立？
难度： 实战
- A. scope 表达获准操作范围，audience 表达令牌预期资源，两者共同参与 API 授权判断
- B. 存在某个 scope 不代表令牌就是签发给当前 API
- C. 遇到“另一个 API 的令牌被错误接受”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
- D. 验证 scope 后可以跳过 issuer 和 audience 校验
查看答案与解析
正确答案D
题目要求找出不成立的判断，“验证 scope 后可以跳过 issuer 和 audience 校验”正是scope 与 audience的典型误区。主规则“scope 表达获准操作范围，audience 表达令牌预期资源，两者共同参与 API 授权判断”描述了实现应依赖的契约，边界“存在某个 scope 不代表令牌就是签发给当前 API”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
016 准备上线涉及scope 与 audience的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“验证 scope 后可以跳过 issuer 和 audience 校验”完成修改，只要本地运行一次成功就立即发布。
- B. 依据“scope 表达获准操作范围，audience 表达令牌预期资源，两者共同参与 API 授权判断”实现，在“存在某个 scope 不代表令牌就是签发给当前 API”成立的环境中验证，并为“另一个 API 的令牌被错误接受”保留可观测证据和回退条件。
- C. 按照“scope 表达获准操作范围，audience 表达令牌预期资源，两者共同参与 API 授权判断”修改代码，但不核对“存在某个 scope 不代表令牌就是签发给当前 API”或目标发布模式。
- D. 只验证“存在某个 scope 不代表令牌就是签发给当前 API”，实现仍继续依赖“验证 scope 后可以跳过 issuer 和 audience 校验”这一未经证明的假设。
查看答案与解析
正确答案B
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“scope 表达获准操作范围，audience 表达令牌预期资源，两者共同参与 API 授权判断”，部署环境满足“存在某个 scope 不代表令牌就是签发给当前 API”，并能在“另一个 API 的令牌被错误接受”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
017 关于元数据发现，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 任何用户提交的 authority 都可安全用于动态发现
- B. OIDC 元数据提供端点、发行者和签名密钥位置，客户端仍需通过受信 HTTPS 地址加载并缓存
- C. 发现文档变化和密钥轮换需要容错，不能信任请求中临时提供的地址
- D. 只要观察到“攻击者诱导服务加载恶意元数据”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案B
正确项给出了元数据发现可直接依赖的规则：“OIDC 元数据提供端点、发行者和签名密钥位置，客户端仍需通过受信 HTTPS 地址加载并缓存”。“发现文档变化和密钥轮换需要容错，不能信任请求中临时提供的地址”是应用规则前必须确认的边界，不是规则本身；“任何用户提交的 authority 都可安全用于动态发现”则把常见现象或实现细节扩大成了平台保证。场景“攻击者诱导服务加载恶意元数据”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
018 生产环境出现“攻击者诱导服务加载恶意元数据”时，针对元数据发现应如何排查？
难度： 进阶
- A. 直接采用“任何用户提交的 authority 都可安全用于动态发现”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“发现文档变化和密钥轮换需要容错，不能信任请求中临时提供的地址”的验证。
- C. 只检查代码是否能够编译，通过后便认定“OIDC 元数据提供端点、发行者和签名密钥位置，客户端仍需通过受信 HTTPS 地址加载并缓存”在当前部署中必然成立。
- D. 先验证“发现文档变化和密钥轮换需要容错，不能信任请求中临时提供的地址”，再使用运行时指标、日志或最小复现检查“OIDC 元数据提供端点、发行者和签名密钥位置，客户端仍需通过受信 HTTPS 地址加载并缓存”是否成立。
查看答案与解析
正确答案D
“攻击者诱导服务加载恶意元数据”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“发现文档变化和密钥轮换需要容错，不能信任请求中临时提供的地址”，再以“OIDC 元数据提供端点、发行者和签名密钥位置，客户端仍需通过受信 HTTPS 地址加载并缓存”组织证据。采用误区“任何用户提交的 authority 都可安全用于动态发现”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
019 评审元数据发现相关实现时，以下哪项判断不成立？
难度： 实战
- A. 任何用户提交的 authority 都可安全用于动态发现
- B. OIDC 元数据提供端点、发行者和签名密钥位置，客户端仍需通过受信 HTTPS 地址加载并缓存
- C. 发现文档变化和密钥轮换需要容错，不能信任请求中临时提供的地址
- D. 遇到“攻击者诱导服务加载恶意元数据”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案A
题目要求找出不成立的判断，“任何用户提交的 authority 都可安全用于动态发现”正是元数据发现的典型误区。主规则“OIDC 元数据提供端点、发行者和签名密钥位置，客户端仍需通过受信 HTTPS 地址加载并缓存”描述了实现应依赖的契约，边界“发现文档变化和密钥轮换需要容错，不能信任请求中临时提供的地址”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
020 准备上线涉及元数据发现的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“任何用户提交的 authority 都可安全用于动态发现”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“OIDC 元数据提供端点、发行者和签名密钥位置，客户端仍需通过受信 HTTPS 地址加载并缓存”修改代码，但不核对“发现文档变化和密钥轮换需要容错，不能信任请求中临时提供的地址”或目标发布模式。
- C. 依据“OIDC 元数据提供端点、发行者和签名密钥位置，客户端仍需通过受信 HTTPS 地址加载并缓存”实现，在“发现文档变化和密钥轮换需要容错，不能信任请求中临时提供的地址”成立的环境中验证，并为“攻击者诱导服务加载恶意元数据”保留可观测证据和回退条件。
- D. 只验证“发现文档变化和密钥轮换需要容错，不能信任请求中临时提供的地址”，实现仍继续依赖“任何用户提交的 authority 都可安全用于动态发现”这一未经证明的假设。
查看答案与解析
正确答案C
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“OIDC 元数据提供端点、发行者和签名密钥位置，客户端仍需通过受信 HTTPS 地址加载并缓存”，部署环境满足“发现文档变化和密钥轮换需要容错，不能信任请求中临时提供的地址”，并能在“攻击者诱导服务加载恶意元数据”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。