请求访问令牌时如何为Azure Blob存储REST请求指定权限范围并管理分级访问权限

首先明确：请求令牌阶段无法直接指定存储侧的细粒度权限 #

你完全没办法在向Azure AD申请访问令牌的环节，直接指定读、写、所有者这类粒度的访问权限，这是由Azure的分层授权架构决定的，不是配置不全的问题。

底层逻辑拆解 #

Azure存储的权限体系是两层独立结构，访问令牌本身只是身份凭证，不承载资源侧的权限分级信息：

• 第一层是应用注册层面的API授权边界：也就是你在API权限页配置的user_impersonation委托权限，作用仅仅是告诉Azure AD「这个应用有资格调用存储服务的接口，不会随便调用其他不相关的Azure服务」，这层完全不区分读、写、所有者的操作粒度。
• 第二层是存储账户的IAM RBAC控制：也就是你在配置流程第三步里设置的角色（存储Blob数据读者、数据参与者、存储Blob数据所有者等），这层才是真正决定你拿到令牌后能执行什么操作的核心规则。
  你在发起令牌请求时填的scope参数，基本固定会用https://storage.azure.com/.default这类标准值，Azure AD不会因为你在请求参数里写了“只读”“可写”这类标识就调整给你的令牌对应的权限。最终的操作权限，完全由「发起请求的用户/服务主体本身被分配的RBAC角色」决定——走用户委托流的场景下，应用只是个代理身份，权限是继承自实际登录用户的。

分级权限的落地实现方案 #

你提到的“要不要配多套独立用户、要不要建多个独立应用适配不同权限”的问题，实际生产中根本不是非此即彼的选择，要优先选维护成本最低的方案：

• 90%以上的场景，完全不需要拆多应用，也不需要为不同权限单独建独立用户：单条应用注册就能支撑全量分级需求。比如面向内部员工的存储访问系统，只需要把不同权限的AD用户/AD安全组，在存储的IAM界面对应分配不同的RBAC角色就行——只读查日志的研发成员分配读者角色，需要上传素材的运营成员分配参与者角色，负责存储运维的管理员分配所有者角色。整个流程里应用只需要注册一次，所有用户通过这个应用拿到的令牌，都会自动继承对应用户本身的RBAC权限，根本不需要为了权限差异重复搭建应用。
• 服务对服务的调用场景也同理：单应用注册下，可以给不同工作负载对应的托管标识/服务主体，分别分配对应粒度的RBAC角色，不需要拆分多应用。
• 只有需要严格做凭证隔离、独立审计的时候，才适合创建多个独立应用：比如给外部合作方的只读访问入口，和内部使用的全量访问入口，为了避免某一套应用的凭证泄露后牵连整个存储账户的安全，才会拆成独立的应用注册，分别配置独立权限。

补充：如果确实需要在每次请求时动态指定权限粒度，并不是在Azure AD访问令牌层面实现的，而是在拿到合法身份令牌后，针对具体的存储对象（容器、单个Blob）生成对应权限范围的SAS令牌，实现单次请求级别的权限控制。

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