第三方 OAuth 接入权限与安全
细粒度授权
RFC 9396 —— 用 authorization_details 表达「对哪个对象做哪个动作」。
scope 只能表达「有没有某一类权限」，表达不了「对哪个对象、做哪个动作」。authorization_details（RFC 9396）补上了这一层，MuoCeon 用它替代了私有的「提权动作」字符串。
第三方应用不适用
当前支持的三类授权详情都对应账号自管理能力（管理验证方式、会话、授权关系）， 只有 MuoCeon 自己的管理端会申请。第三方应用应使用 scope，见 scope 与受众。本页说明机制，便于你理解令牌结构。
请求格式
authorization_details 是一个 JSON 数组，作为字符串放进授权请求参数：
&authorization_details=[{"type":"muoceon_session_management","actions":["session:revoke"]}]单个元素的通用字段：
| 字段 | 必填 | 说明 |
|---|---|---|
type | ✅ | 授权详情类型，必须在服务端白名单内 |
actions | 可选 | 允许的动作列表；省略表示该类型下的全部动作 |
locations | 可选 | 限定的位置范围 |
identifier | 可选 | 限定的对象标识 |
数量上限 10 条；type 之外的未知字段会原样保留，便于下游按自己的语义读取。
三类授权详情
type | 含义 | 允许的动作 |
|---|---|---|
muoceon_credential_management | 认证因子管理 | passkey:add、passkey:delete、authenticator:add、authenticator:delete、password:update、recovery_code:delete、oauth:unlink |
muoceon_session_management | 登录会话管理 | session:revoke |
muoceon_grant_management | OAuth 授权关系管理 | grant:revoke |
这份白名单是「客户端能申请什么」的唯一依据。若放任任意动作字符串进入授权码或令牌，动作判定就退化成「客户端自己给自己授权」。
服务端的校验
提交的每一条详情都会被逐项比对：
type不在白名单 →400 OAUTH_INVALID_AUTHORIZATION_DETAILSactions里出现该类型未允许的动作 → 同上- 结构不合法（不是数组、超过 10 条、
type为空）→ 同上
同意页会把通过校验的详情展开成人类可读的权限条目展示给用户。
令牌里的 authorization_details
授权成功后，详情会进入访问令牌：
{
"authorization_details": [
{ "type": "muoceon_session_management", "actions": ["session:revoke"] }
]
}资源服务器判定动作时按这条规则：
- 找到对应
type的详情； actions缺省 → 该类型下全部动作放行；actions显式列出 → 必须精确命中。
解析失败的详情一律当作「没有细粒度授权」处理，不会因为异常把请求变成 500。
两条容易踩的边界
- 刷新令牌不恢复详情：
authorization_details只在首次授权时成立，刷新后令牌不再携带。需要新的细粒度授权，必须让用户重新走一次授权流程。 - 详情与 scope 是两套门：只有详情、scope 不够，请求依然会被
insufficient_scope拦下；反之亦然。