認証と承認は、あらゆる開発プラットフォームで重要な役割を果たします。 SharePoint Online モダン開発 Azure Active Directory (AzureAD) と Open Authorization 2.0 (OAuth 2.0) プロトコルの分野では、セキュリティ インフラストラクチャの重要な要素です。
実際、Azure Active Directory はすべての Microsoft 365 テナントのカバーの下にあり、ネイティブ サービスやカスタム開発アプリケーションにアクセスするときの認証と承認の要件を処理します。 OAuth 2.0 は、ネイティブ ワークロードとカスタム開発アプリケーションへのアクセスを承認するために使用される業界プロトコルです。
重要
この記事では、いわゆる PnP コンポーネント、サンプル、ツールを参照します。これは、サポートを提供するアクティブなコミュニティによってサポートされるオープンソース資産です。 公式の Microsoft サポート チャネルのオープン ソース ツールのサポート用 SLA ではありません。 ただし、これらのコンポーネントまたはサンプルは、Microsoft でサポートされているすぐに使用できる API と機能を使用しています。
必要に応じて、記事全体を読む代わりに、次のビデオをwatchできます。これは、より詳細なリファレンスと見なすことができます。
SharePoint Frameworkでの AzureAD と OAuth 2.0 のロールについて
Microsoft Office SharePoint Onlineでは、SharePoint Framework (SPFx) ソリューションを開発するときに、Microsoft Graph のほか、OAuth 2.0 と Azure Active Directory に依存する他のサードパーティ API を使用できます。 具体的には、既定では、SharePoint Frameworkでは、外部 API は MSGraphClient または AadHttpClient を介して使用でき、"SharePoint Online クライアント拡張 Web アプリケーション プリンシパル" という名前の定義済みの Azure Active Directory アプリケーションを利用できます。
注:
SharePoint Framework ソリューション内から Microsoft Graph を使用する方法の詳細については、「MSGraphClientV3 を使用して Microsoft Graph に接続する」の記事を参照してください。 SharePoint Framework内から他のサードパーティ製 API を使用する方法の詳細については、「SharePoint Framework ソリューションの Azure AD で保護された API に接続する」の記事を参照してください。
重要
ターゲット API への専用の分離されたアクセス権を持つ必要があるシナリオがあります。 このようなシナリオでは、SharePoint Framework ソリューションのドメイン分離構成に依存できます。 ドメイン分離シナリオの詳細については、 分離された Web パーツに関する記事を参照してください。
"SharePoint Online クライアント拡張 Web アプリケーション プリンシパル" アプリケーションは、Microsoft 365 テナントのMicrosoft Office SharePoint Onlineによって事前に登録されており、すべてのSharePoint Framework ソリューションが一意のアプリケーションを共有して、Microsoft Graph とその他のサードパーティ製 API の両方にアクセスできます。 この記事では、SharePoint Framework コンテキストでの Azure Active Directory と OAuth 2.0 のロールについて説明します。
アクセス トークンについて
Azure Active Directory に登録され、OAuth 2.0 で保護された API を使用するには、アクセス トークンを指定する必要があります。これは、定義上、リソースを保護するために使用される不透明な文字列です。 Azure Active Directory と他の多くのベンダー固有の ID プラットフォームでは、アクセス トークンは一連の要求を含む JSON Web トークン (JWT) です。 要求は、アクセス トークンによって記述されたサブジェクトに関するアサーションであり、トークンは発行者 (このコンテキストでは Azure Active Directory) によってデジタル署名され、トークンの受信者が発行者を信頼するため、アサーションが true であることが保証されます。
注:
Open Authorization 2.0 プロトコルの詳細については、 OAuth 2.0 Authorization Framework の仕様を参照してください。 また、 OAuth 2.0 Acccess Tokens のドキュメント JSON Web トークン (JWT) プロファイルを読み取るアクセス トークンの JWT トークン形式に関する追加情報も確認できます。
アクセス トークンは、HTTP 承認ヘッダーを介してターゲット API/サービスに提供され、具体的には Azure Active Directory のフィールドでは、 ベアラー型の承認トークンです。
注:
"ベアラー" の意味と、Authorization ヘッダーの実際のアクセス トークン値の前にベアラーの種類を指定する必要がある理由が気になっている場合 は、OAuth 2.0 Authorization Framework: Bearer Token Usage という仕様を読むことができます。
委任されたアクセス許可スコープとアプリケーションアクセス許可スコープ
アクセス トークンで説明されているメイン情報の 1 つは、ターゲット API/サービスを使用するために付与されるアクセス許可です。
アクセス トークンには、次の 2 つのメイン種類のアクセス許可があります。
- 委任: は、サインインしているユーザーとして機能するターゲット API/サービスを使用できるトークンです。
- アプリケーション: サインインしているユーザーなしで、アプリケーション ID でターゲット API/サービスを使用できるようにするトークンです。 一般的なシナリオは、バックグラウンド タスク、デーモンなどです。
アクセス トークンで委任されたアクセス許可を使用する場合、トークンに関連付けるアクセス許可スコープは、サインインしているユーザーのアクセス許可と、API/サービスを使用するアプリケーションのアクセス許可の積集合の結果になります。 つまり、ユーザーが高レベルのアクセス許可 (たとえば、電子メール メッセージの読み取りと書き込み) を持つ可能性がある場合でも、アプリケーションが低レベルのアクセス許可 (電子メール メッセージの読み取り専用など) で Azure Active Directory に登録されている場合、アプリケーションに付与されるアクセス許可は、ユーザーとアプリケーションの両方のアクセス許可 (つまり、現在の例では電子メール メッセージの読み取り専用) の共通部分になります。
トークンを発行して完全に有効にするには、現在のユーザーの個人リソースに関連するアクセス許可に対する明示的なユーザーの同意、またはテナント全体のリソースに関連するアクセス許可に対するテナント管理者の同意が必要です。
アクセス トークンでアプリケーションのアクセス許可を使用する場合、通常、付与されるアクセス許可にはテナント管理者の同意が必要です。そのため、そのようなアプリケーションはテナント全体のターゲット リソースにアクセスできるため、管理者の承認が必要です。
SharePoint Frameworkソリューションでは、委任されたアクセス許可を持つアクセス トークンのみが取得されます。つまり、Microsoft Graph と、サインインしているユーザーとして機能するその他の API/サービスのみを使用します。
SharePoint Framework アクセス トークンと委任されたアクセス許可スコープについて
アクセス トークンの役割と形式をより深く理解するには、この記事に関連するSharePoint Frameworkのサンプル「Microsoft Graph の使用」を参照してください。 次のスクリーンショットでは、サンプルのユーザー インターフェイスを確認できます。
サンプル Web パーツは、Microsoft が提供 する jwt.ms Web サイトに依存しています。ここで、アクセス トークンの内容を調べることができます。
SharePoint Framework Workbench でサンプル Web パーツを実行し、[Microsoft Graph のアクセス トークン内を見る] ボタンを押すと、jwt.ms Web サイトに移動して、アクセス トークンの内容を確認できます。 次のスクリーンショットでは、サンプルのアクセス トークンの jwt.ms Web サイトの出力を確認できます。
すべての JWT アクセス トークンには要求があり、委任されたアクセス許可スコープを持つSharePoint Framework クライアントに発行されるアクセス トークンの最も重要なものの一覧を見つけることができます。
- aud: トークンの対象ユーザー。つまり、トークンが発行された API/サービスです。
- iss: トークンの発行者。トークンを発行した Azure Active Directory テナントです。
- iat: "発行時刻" を表し、トークンが発行された時点を表します。
- nbf: "not before time" を表し、トークンをターゲット対象ユーザーが受け入れてはならない前の時点を表します。
- exp: は "有効期限" を表し、対象ユーザーがトークンを受け入れてはならない時点を表します。
- app_displayname: トークンが発行されたアプリケーションの名前 (ターゲット対象ユーザーのコンシューマー アプリケーション)。
- name: トークンが関連付けられているユーザーの完全な名前。
- scp: 現在のアクセス トークンに関連付けられている委任されたアクセス許可スコープ。
- upn: トークンが関連付けられているユーザーのユーザー プリンシパル名。
上記のサンプルのように Microsoft Graph を使用している場合、 aud 要求は Microsoft Graph (https://graph.microsoft.com) を記述します。 サード パーティの API/サービスを使用している場合、 aud 要求はそのターゲット API を記述します。 SharePoint Framework ソリューションのapp_displayname要求は"SharePoint Online クライアント機能拡張 Web アプリケーション プリンシパル" であることに注意してください。これは、この記事の概要で参照していたアプリケーションです。
注:
ドメイン分離ソリューションの場合、 app_displayname 要求は、SharePoint Online サービスによって Azure Active Directory に登録された専用アプリケーションの 1 つです。
クライアント側では、つまり、SharePoint Frameworkでは、アクセス トークンの実際のコンテンツに依存しないでください。 提供されるサンプルは、セキュリティ モデルのしくみを理解するためだけに用意されています。 ただし、一般的なシナリオでは、SharePoint Frameworkのすぐに使用できる機能を利用するだけで、コードから外部 API を使用するすべての配管が非表示になります。
サービス側では、Microsoft Graph を使用している場合は、提供されたアクセス トークンを評価し、要求された API エンドポイントへのアクセスを承認 (または拒否) する必要があります。 実装したサード パーティ製の API/サービスを使用する場合は、Microsoft Azure でサービスをホストしている場合は、Microsoft Azure の構成オプションに依存するか、Microsoft 認証ライブラリ (MSAL) や Microsoft.Identity.Web ライブラリなどに依存してトークンを検証および承認できます。
注:
Microsoft 認証ライブラリに関する追加情報については、「Microsoft 認証ライブラリ (MSAL) の概要」を参照してください。 Microsoft.Identity.Web ライブラリの詳細については、Microsoft Identity Web 認証ライブラリに関する記事を参照してください。
推奨されるコンテンツ
このトピックに関する追加情報については、次のドキュメントを参照してください。