Microsoft Graph にベスト プラクティスを適用する

  • 3 分

このユニットでは、Microsoft Graph を最大限に活用し、エンド ユーザーに対するアプリケーションの信頼性を高めるために適用できるベスト プラクティスについて説明します。

認証

Microsoft Graph のデータにアクセスするには、アプリケーションを使用して OAuth 2.0 アクセス トークンを取得し、次のいずれかのメソッドで Microsoft Graph に提示する必要があります。

  • HTTP Authorization 要求ヘッダー ("ベアラー" トークンとして)
  • Graph クライアントのコンストラクター (Microsoft 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 の使用条件に違反しない場合にのみ実行する必要があります。 また、アプリケーションでは、保持と削除の適切なポリシーも実装する必要があります。