将最佳做法应用于 Microsoft Graph

已完成

本单元介绍了一些最佳做法,你可以使用这些做法最大限度地利用 Microsoft Graph,为最终用户提供更可靠的应用程序。

身份验证

为了访问 Microsoft Graph 中的数据,应用程序需要获取 OAuth 2.0 访问令牌,并按以下任一方法将其提供给 Microsoft Graph:

  • HTTP 授权请求头,作为持有者令牌
  • 使用 Microsoft Graph 客户端库时的 Graph 客户端构造函数

使用 Microsoft 身份验证库 API MSAL 获取 Microsoft Graph 的访问令牌。

在应用中采用以下最佳做法来进行许可和授权:

  • 使用最小特权。 仅请求必要的权限,并且仅在需要时请求。 对于应用程序调用的 API,请检查方法主题中的权限部分。 例如,请参阅创建用户并选择最小特权权限。

  • 根据场景使用正确的权限类型。 如果你要生成的是有登录用户交互式应用程序,则你的应用程序应使用委派权限。 但是,如果你的应用程序在没有登录用户的情况下运行(如后台服务或守护程序),该应用程序应使用应用程序权限。

    注意

    对交互式场景使用应用程序权限会使应用程序存在合规性和安全性方面的风险。 请务必检查用户的权限,确保他们不会对信息进行不需要的访问,或者绕过由管理员配置的策略。

  • 考虑最终用户和管理员体验。 直接影响最终用户和管理员体验。 例如:

  • 考虑多租户应用程序。 预期客户在不同的状态下具有不同的应用程序和许可控制措施。 例如:

    • 租户管理员可以禁用最终用户许可应用程序的功能。 在这种情况下,管理员需要代表其用户进行许可。

    • 租户管理员可以设置自定义授权策略,例如阻止用户读取其他用户的配置文件,或将自助服务组创建限制为一组有限的用户。 在这种情况下,当代表用户操作时,应用程序应该会处理 403 错误响应。

有效地处理响应

根据对 Microsoft Graph 发出的不同请求,应用程序应准备好处理不同类型的响应。 需要遵循以下一些最重要的做法,以确保你的应用程序为最终用户提供可靠且可预测的行为。 例如:

  • 分页:在查询资源集合时,由于服务器端页面大小的限制,应预期 Microsoft Graph 会在多个页面中返回结果集。 你的应用程序应始终处理响应具有分页性质的可能性,并使用 @odata.nextLink 属性获取下一个分页结果集,直到读取完结果集的所有页面。 最后一页不包含 @odata.nextLink 属性。 有关详细信息,请访问分页

  • 演化枚举:将成员添加到现有枚举可能会破坏已在使用这些枚举的应用程序。 演化枚举是 Microsoft Graph API 用来将新成员添加到现有枚举,而不会对应用程序造成重大更改的一种机制。 默认情况下,GET 操作仅返回演化枚举类型的属性的已知成员,并且你的应用程序只需处理已知成员。 如果将应用程序设计为同时还处理未知成员,你可以选择使用 HTTP Prefer 请求头来接收这些成员。

在本地存储数据

应用程序最好调用 Microsoft Graph,以便在必要时实时检索数据。 应该仅在特定场景需要时在本地缓存或存储数据。 如果该用例符合使用条款和隐私策略,并且不违反 Microsoft API 使用条款,则应用程序还应实现适当的保留和删除策略。