Azure中为何需要App Registration？它和App Service有什么关联？

应用注册的核心作用 #

• 应用注册是Azure AD所有身份交互的基础实体，只要服务需要和Azure AD做身份校验、获取受Azure AD保护的资源（比如Microsoft Graph、自定义API）的访问权限，就需要先创建应用注册。你公司要求SPA和API单独创建应用注册，本质是做身份边界隔离：SPA是面向用户的公开客户端，API是受保护的资源服务，二者权限范围、访问规则完全独立，分开注册符合最小权限原则，也方便后续单独做权限审计、配置生命周期管理。

为什么可以不用机密客户端方案，直接用托管身份访问Microsoft Graph #

• 托管身份本质是Azure平台自动维护生命周期的特殊应用注册：平台会自动创建对应的服务主体、自动轮换密钥，完全不需要你手动管理Client Secret或者证书，你提到的通过New-AzureAdServiceAppRoleAssignment给托管身份授予Graph角色的方案是完全可行的，比手动维护机密的方案更安全。你现在参考其他项目用的机密客户端方案，大多是历史开发习惯或者旧规范要求，并不是技术上的强制要求。

是否需要同时保留两类身份凭证 #

• 不需要二选一，二者的适用场景不同：
  • 如果你的API需要作为资源服务被SPA或其他客户端调用，你必须保留API对应的应用注册：你需要在这个应用注册里定义API的自定义权限、配置令牌签发规则，客户端请求你API的令牌时，也需要用这个应用注册的Client ID作为受众。
  • 如果你的API需要作为客户端访问Microsoft Graph或其他受保护资源，可以二选一：要么用现有API应用注册的Client Secret/证书走机密客户端流，要么给App Service开通托管身份，用托管身份拿令牌。托管身份方案不需要处理密钥轮换、不会出现密钥泄露风险，是更推荐的方案。

是否应该用应用注册+机密客户端的方式访问Microsoft Graph #

• 技术上可行，但不是最优方案。机密客户端方案需要你手动维护Client Secret的生命周期，过期前要手动更新，一旦密钥泄露就会有越权访问Graph的风险。托管身份方案所有凭证由Azure自动维护，代码中只需要调用Azure.Identity库的ManagedIdentityCredential就能直接获取令牌，不需要配置任何密钥，更安全也更省心。如果公司规范强制要求必须使用自行维护的应用注册机密，可以继续用现有方案，否则优先选择托管身份。

代码层面App Service和应用注册的关联逻辑 #

• 二者没有强制的绑定关系，关联是通过配置的身份参数实现的：
  • 如果你用机密客户端流，只需要在App Service的配置中将对应应用注册的ClientId、ClientSecret、租户ID存为环境变量，代码中读取这些参数初始化ConfidentialClientApplication即可，不会有平台层面的自动绑定。
  • 如果你用托管身份，开通系统分配托管身份之后，Azure会自动给App Service运行环境注入IDENTITY_ENDPOINT、IDENTITY_HEADER两个环境变量，Azure.Identity库会自动读取这些变量获取令牌，不需要配置任何应用注册参数，托管身份对应的服务主体已经由Azure自动关联。
  • 如果你需要让API作为受保护资源校验传入的令牌，只需要在代码的JWT验证配置中，把ValidAudience设为API应用注册的Client ID，ValidIssuer设为对应租户的令牌签发地址即可，令牌校验逻辑和部署的App Service实体没有绑定关系。

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