本文提供有关如何通过许可、手动授权和其他授权系统授予代理访问权限的指导。 了解可用于授权代理访问 Microsoft 365 资源的不同方法，以及何时使用每个方法。
先决条件
- 代理标识蓝图和至少一个从该蓝图创建的代理标识。
- 具有有效重定向 URI 的代理标识蓝图。
如何请求许可（委派权限或应用程序权限）
用户或管理员可以通过在 OAuth 流期间同意 API 权限来授予代理对数据的访问权限。 本部分介绍如何请求代理的委派权限和应用程序权限的同意。
何时使用委派权限或应用程序权限
你请求的权限类型取决于代理的操作方式以及它需要访问的资源。
当交互式代理需要代表已登录用户执行作时，请使用委派权限。 例如，读取该用户的邮件、日历或文件。 委派访问权限是在令牌的 scp 声明中传递的。
当自治代理在没有用户的情况下运行并需要仅应用程序访问权限时，使用应用程序权限。 例如，读取所有用户的资料。 应用权限显示在令牌的角色声明中。
有关详细信息，请参阅 权限和同意概述
同意的工作原理
对于委派权限，当您将用户重定向到 Microsoft 身份平台 /authorize 终结点时，他们会查看诸如 User.Read 和 Mail.Read 的权限范围。 如果授予许可，Microsoft Entra ID 会将 OAuth2PermissionGrant 从代理（客户端）记录到资源（如 Microsoft Graph）。 除非同意更改，否则该资源的未来委托令牌包括已批准的范围 scp ，而无需重新分配。 如果你的应用请求管理员受限权限的许可，你的用户会收到错误。 管理员直接请求这些权限。 有关详细信息，请参阅 管理员限制的权限。
生成同意 URL
生成同意 URL 时，客户端 ID 应为代理标识的 ID。
有关详细信息，请参阅 通过用户同意请求权限。 某些权限需要管理员同意，然后才能在租户中授予这些权限。 有关详细信息，请参阅 Microsoft标识平台上的管理员同意
如何手动授予授权（委派或应用程序）
可以直接创建基础授权对象。 这对于想要自动执行授权或避免交互式提示的情况非常有用。
- 手动授予委派的权限。 将客户端 ID 设置为代理标识 ID。
- 手动授予应用程序权限（应用角色分配）。 将主 ID 设置为代理身份 ID。
如何通过访问包管理访问权限
使用访问包，可以为许多具有相同访问需求的 AI 代理启用标准化访问。 访问包可以包括 Entra 角色、OAuth2 委派权限、应用程序权限授予以及安全组成员身份。 然后，代理可以请求访问包，或者发起人或管理员可以为其请求，一旦获得批准，代理标识或代理用户将收到访问权限，直到分配被吊销或过期。 有关更多信息，请参阅 代理标识的访问套件。
其他授权系统
除了应用角色分配、组成员身份和 OAuth2 权限授予外，还可以通过多种方式授权代理。 这些替代系统为分配针对不同平台、服务和安全要求定制的访问提供了灵活性。 以下部分总结了代理授权的一些方法。
Azure 基于角色的访问控制 （Azure RBAC）
将 Azure 角色分配到范围最窄的代理标识（资源、资源组、订阅）。 例如，可以在单个保管库上授予 Key Vault 读取者角色，以便代理可以读取机密，而无需广泛的目录或租户权限。 有关详细信息和分步指南，请参阅 Azure RBAC 文档。
Microsoft Entra 角色
某些低特权目录角色可能会被分配给代理，用于元数据或读取场景。 平台策略阻止代理使用高特权角色。 若要详细了解Microsoft Entra 角色和 PIM，请参阅 Microsoft Entra 角色。
Exchange 基于角色的访问控制 (RBAC)
Exchange RBAC（Role-Based 访问控制）允许管理员向 Exchange 资源委派权限。 它确保代理可以获得精细的授权，例如对一个邮箱或几个邮箱的自治访问。 有关信息，请参阅 Exchange Online 中应用程序的基于角色的访问控制
Teams 资源特定同意（RSC）
Teams Resource-Specific 许可（RSC）为 Microsoft Teams 中的代理启用精细权限分配。 RSC 允许你为每个团队的应用程序或代理分配权限，而不是在整个租户级别上分配权限。 如果希望仅限制对特定团队中的资源和数据的访问，此方法特别有用。 此类数据包括频道、消息或名单信息，而无需授予更广泛的组织权限。 有关详细信息，请参阅 适用于您的 Teams 应用的资源特定授权。
自定义（第三方）API
代理可以调用其他受 OAuth 保护的 API。 确保资源应用程序及其服务主体存在于租户中，定义所需的范围/应用角色，并遵循相同的委托或应用权限流。 有关详细信息，请参阅 Microsoft 标识平台中Microsoft的权限和同意指南。