OAuth 2.0流程如何强制限制授权scope 禁止越权请求

结论先说：完全可以在注册客户端（签发client_id、client_secret）的环节从授权服务器层面锁死允许申请的scope范围，不需要依赖业务侧代码做校验，哪怕后续开发写错了scope参数申请额外权限，请求会直接被授权服务器拦截失败。

管控逻辑说明 #

这个能力是OAuth2.0生态里主流授权服务的标准安全配置，校验逻辑完全跑在授权服务器侧，和你自己写的业务代码无关：只要你给对应客户端配置了scope白名单，所有授权请求、token换发请求携带的scope只要超出白名单范围，服务端会直接返回错误，不会进入用户授权页，也绝不会签发带超范围权限的access token。

哪怕请求里完全不传递scope参数，配置了白名单的客户端也只会拿到白名单范围内的默认权限，不会出现权限溢出的问题。

你实际对接Google APIs的配置方法 #

直接在Google Cloud控制台操作即可，不需要改业务代码：

• 找到你项目下对应的OAuth 2.0客户端ID配置项，进入编辑页
• 在「已授权的范围」板块，只添加你业务实际需要的scope到白名单，不要勾选多余权限
• 保存配置后即时生效，后续所有发起的授权请求只要带了白名单外的scope，Google会直接返回invalid_scope错误，授权流程直接中断，举个错误响应示例：

{
  "error": "invalid_scope",
  "error_description": "The requested scope is invalid, unknown, or malformed. One or more scopes are not permitted for this client."
}

• 如果你用的是服务账号（Service Account）做服务端对接，限制会更严格：你在IAM里给服务账号绑定什么角色、什么权限，服务账号就只能申请对应范围的scope，多申请的直接被拦截，没有绕过空间。

Facebook场景的对应规则 #

你举例的Facebook授权逻辑也是一致的：在Meta开发者后台创建应用后，只需要在「权限与功能」页面开通你需要的照片访问权限（比如user_photos），其余权限都不申请开通的话，任何授权请求里带了未开通的scope（比如你例子里的posts、email），请求都会直接失败，不会弹出用户授权窗口。

内容的提问来源于stack exchange，提问作者pkaramol