跳到页面内容
每日网安DAILY SECURITY TERMS
跳到互动练习
互动课堂 / 委托授权交换站DAILY / SECURITY TERMS

051 / 身份与访问 / OAuth

让应用替你办事，要交出多少权限？

OAuth · OAuth

读书助手只需要读取笔记，却不该因此拿到你的密码或修改资料的权限。沿着授权码、令牌与 API 请求，找到每一步允许做事的依据。

开始探索 ↓8–12 分钟
动手实验 · 场景判断 · 实用检查

女孩把带日历图案的钥匙交给日历角色，门内放着信件，旁边密码气泡被打叉。钥匙比喻限定范围的授权；它仍需妥善保管，图中日历例子与实验中的笔记委托遵循同一边界。

展开读图提示
读图提示
角色与机制
女孩比喻资源所有者，日历角色比喻第三方应用，带日历标记的钥匙比喻有范围限制的访问令牌。
风险在哪里
交出账户密码会暴露过多权限；令牌若泄露或授权范围过大，也可能被滥用。
防护与边界
核对请求的 scope，使用授权码流程与 PKCE，严格验证回调地址；OAuth 主要解决委托授权，登录身份通常还需 OIDC。

OAuth · 本课场景

女孩把带日历图案的发光钥匙交给日历角色，背后的门内放着信件，旁边攻击者的密码气泡被打上叉。

女孩把带日历图案的钥匙交给日历角色，门内放着信件，旁边密码气泡被打叉。钥匙比喻限定范围的授权；它仍需妥善保管，图中日历例子与实验中的笔记委托遵循同一边界。

读图提示
角色与机制
女孩比喻资源所有者，日历角色比喻第三方应用，带日历标记的钥匙比喻有范围限制的访问令牌。
风险在哪里
交出账户密码会暴露过多权限；令牌若泄露或授权范围过大，也可能被滥用。
防护与边界
核对请求的 scope，使用授权码流程与 PKCE，严格验证回调地址；OAuth 主要解决委托授权，登录身份通常还需 OIDC。

按 Esc 或点击画面外侧关闭。打开原图 ↗

本课任务 / OAuth

分清谁在授权、谁在调用、令牌给谁用，以及被允许的具体动作。

  • 识别 OAuth 的四种角色
  • 检验授权码绑定、PKCE 与单次兑换
  • 分别判断目标资源、权限范围与有效期

OAuth 委托的是什么？

资源所有者允许客户端访问受保护资源，授权服务器发放令牌，资源服务器检查请求。客户端能取得受限授权，无须获得用户在资源服务上的密码。[1]

授权码就是访问令牌吗？

不是。授权码是用于兑换令牌的短期、单次凭据，并与客户端和回调等条件绑定；访问令牌才用于受保护资源请求。拿到授权码不等于可以直接调用任意 API。[1][2]

有令牌就说明用户登录了吗？

OAuth 主要定义委托授权。客户端不能把任意访问令牌当成自己的用户登录证明；OpenID Connect 在 OAuth 之上定义身份层及 ID Token 的验证规则。[5]

亲手探索 / 不同条件，不同结果

一份委托，经过兑换与资源服务器两道检查。

在小珊、读书助手、海湾授权中心和资源 API 之间选择授权范围、兑换记录、目标动作与令牌时间。先预测会在哪一层停止；公共浏览器客户端固定要求 S256，不发送真实请求。

委托边界对照台 · OAuth 2.0

拿到委托，究竟能替谁做什么？

读书助手想代小珊操作资源。把“授权码能否兑换”和“令牌能否用于这个动作”分开检查，再判断哪一道边界应当停下。

资源所有者
小珊
决定授予哪些范围
公共客户端
读书助手
reader-spa，不能保守客户端秘密
授权服务器
海湾授权中心
处理授权并签发访问令牌
资源服务器
笔记 / 资料 API
检查令牌与每次资源操作

限定场景：单一授权服务器、公共浏览器应用、授权码 + S256 PKCE、固定 HTTPS 回调。下方是已知条件卡，不会生成授权码、计算 PKCE 或联系任何服务。

已授予的范围

资源所有者
小珊
接收 API
notes-api
scope
notes:read

目标动作需要

目标 API
notes-api
所需 scope
notes:write
登录身份
不能由访问令牌直接推定
固定 HTTPS 回调、原 client_id、未使用且未过期的授权码、一次性交易关联均匹配；服务器确认支持并执行 S256 PKCE，verifier 与原 challenge 相符。
本实验另假设令牌来源可信、未撤销，并满足小珊的资源所有权约束。scope 名称是本例 API 定义的，不是 OAuth 统一权限表。
⑤ 预测：这一组条件会走到哪里？

尚未运行。先预测，再推进本地教学模型。

再试一次：保留只读委托，把修改改成读取；再换成资料 API。最后保持可访问配置，只把 verifier 改为不匹配。哪一层变化了？PKCE 为什么不能让只读权限变成写权限？

IETF：OAuth 角色（新窗口）IETF：公共客户端与 PKCE（新窗口）OWASP：OAuth 安全边界（新窗口）

随手查 / 把理解带回实际工作

理解机制之后，检查这些细节。

实验是简化模型。真实环境需要明确业务规则、验证失败路径，并持续维护配置与证据。

01 / 实用细节

请求范围与实际获准范围分开记录

客户端只申请当前功能所需的 scope，授权服务器可以收窄授权。API 应按实际令牌及服务端政策判断；同意读取笔记，不能推导出可改笔记、读资料或访问别人的对象。[1][3]

02 / 实用细节

让授权码绑定到本次兑换

PKCE 为每次流程创建高熵 verifier，先发送其 S256 challenge，兑换时再核对。错误 verifier 或缺少必需 PKCE 应失败；它保护授权码交换，不会让恶意客户端自动变可信。[2][3]

03 / 实用细节

回调地址与客户端不能模糊匹配

本页 Web 客户端使用预登记的完整回调地址，授权与兑换阶段都核对相应绑定。client_id 是标识，公共客户端不能把内置字符串当成能保密的 client_secret。[1][3]

04 / 实用细节

兑换成功也不允许再次使用授权码

授权码应短期有效且单次兑换。实现需要拒绝重用，并处理并发兑换、错误客户端与回调不一致；不要把重新提交成功响应当成另一份新的授权。[1]

05 / 实用细节

资源服务器检查范围、目标与时效

有效令牌必须适用于当前资源和动作。Bearer 令牌的持有者可能冒用它，应保护传输和存储，避免进入 URL 或日志；PKCE 不防护已经泄露的访问令牌。[4][3]

06 / 实用细节

需要身份登录时明确采用 OIDC

登录客户端应按 OIDC 检验 ID Token 的签发者、受众、有效期和本次流程关联。ID Token 与访问令牌各有接收者和用途，不能只因两者都像 JWT 就互换。[5]

从模拟，到验证

找一个获准的环境，实际检查一次。

勾选用于本页自查，不会自动标记整课已学会。练习与清单刷新后重置。

本页已检查 0 / 5 项

实际检查清单
30 秒场景小测

应用只需读日程却申请读写全部邮箱，应该？

能解释原因，再标记学会。

小测结果同步错题本；“已学会”沿用原有本地学习记录。

资料与依据

  1. IETF RFC 6749 · OAuth 2.0 ↗

    四种角色、公共客户端、scope 与授权码绑定；安全建议结合 RFC 9700

  2. IETF RFC 7636 · PKCE ↗

    verifier、S256 challenge 与授权码兑换核对

  3. IETF RFC 9700 · OAuth 2.0 Security BCP ↗

    回调精确匹配、PKCE、授权范围与令牌目标限制

  4. IETF RFC 6750 · Bearer Token Usage ↗

    Bearer 凭据泄露、传输与资源请求的安全边界

  5. OpenID Connect Core 1.0 · Identity and ID Tokens ↗

    OAuth 上的身份层及 ID Token 验证

本页场景、人物与数据均为教学示例。互动选择不会上传；收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期：2026-10-08。