登录成功只能证明身份，不能证明用户有权读取某笔订单。接口接受订单 ID 后直接查询返回，是多租户与多部门系统需要重点检查的路径。授权必须结合当前资源与业务操作。
角色检查之外还要看资源归属
同样是销售角色，未必能读取其他团队客户。先确认订单属于哪个租户、部门和业务状态，再判断当前身份是否允许执行查看、修改或退款。不要完全相信前端隐藏按钮已经限制了操作。
授权放在可信服务边界
网关可以验证凭证，但目标服务掌握更完整的资源语义。对于服务间调用，也应明确调用方权限和代表用户的范围。用一个拥有全部权限的内部账号替所有请求执行，会让责任和边界难以区分。
查询与导出都要覆盖
列表过滤正确不代表详情接口正确，普通查询安全也不代表批量导出安全。将后台任务、附件下载和历史查询纳入检查，避免某个辅助入口绕过同样的授权规则。
验收相邻资源访问
准备不同租户、不同归属与不同状态的数据，尝试替换资源 ID、重复提交旧链接和调用隐藏操作。预期结果要包括允许与拒绝场景，并确认错误响应不泄露不必要信息。
常见问题：所有权限规则都放进一个公共方法好吗？
公共基础判断可以复用，但具体业务授权需要保持可理解的资源语义，避免形成无法审查的巨型条件函数。
技术参考：微软：基于资源的授权。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果内部团队需要把这些约定落到可运行的工程中，可以通过微服务基础架构建设沟通接口、公共能力与交接范围，先以一个业务场景验证方案。