次の方法で共有

v1.0 のアプリケーションの種類

警告

このコンテンツは、以前の Azure AD v1.0 エンドポイント用です。 新しいプロジェクトには Microsoft ID プラットフォームを使用します。

Azure Active Directory (Azure AD) では、業界標準のプロトコル OAuth 2.0 または OpenID Connect に基づいて、さまざまな最新のアプリ アーキテクチャの認証がサポートされています。

次の図は、シナリオとアプリケーションの種類と、さまざまなコンポーネントを追加する方法を示しています。

アプリケーションの種類とシナリオ

Azure AD でサポートされる 5 つの主要なアプリケーション シナリオを次に示します。

コードの操作を開始する前に、各種類のアプリの詳細を確認し、高レベルのシナリオを理解するためのリンクに従います。 また、v1.0 エンドポイントまたは v2.0 エンドポイントで動作する特定のアプリを作成するときに知る必要がある違いについても学習できます。

注

v2.0 エンドポイントでは、すべての Azure AD シナリオと機能がサポートされているわけではありません。 v2.0 エンドポイントを使用する必要があるかどうかを判断するには、 v2.0 の制限事項を参照してください。

ここで説明するアプリとシナリオは、さまざまな言語とプラットフォームを使用して開発できます。 これらはすべて、コード サンプル ガイドで入手できる完全なコード サンプル ( シナリオ別の v1.0 コード サンプル とシナリオ 別の v2.0 コード サンプル) でサポートされています。 コード サンプルは、対応する GitHub サンプル リポジトリから直接ダウンロードすることもできます。

さらに、アプリケーションでエンド ツー エンド シナリオの特定の部分またはセグメントが必要な場合は、ほとんどの場合、その機能を個別に追加できます。 たとえば、Web API を呼び出すネイティブ アプリケーションがある場合は、Web API も呼び出す Web アプリケーションを簡単に追加できます。

アプリの登録

Azure AD v1.0 エンドポイントを使用するアプリの登録

Azure AD に認証を委託するアプリケーションは、ディレクトリに登録する必要があります。 この手順では、アプリケーションの場所の URL、認証後に応答を送信する URL、アプリケーションを識別するための URI など、アプリケーションについて Azure AD に通知します。 この情報は、いくつかの重要な理由で必要です。

  • Azure AD は、サインオンを処理するとき、またはトークンを交換するときに、アプリケーションと通信する必要があります。 Azure AD とアプリケーションの間で渡される情報には、次のものが含まれます。

    • アプリケーション ID URI - アプリケーションの識別子。 この値は、呼び出し元がトークンを必要とするアプリケーションを示すために、認証時に Azure AD に送信されます。 さらに、この値はトークンに含まれるため、アプリケーションは、それが目的のターゲットであることを認識します。
    • 応答 URL と リダイレクト URI - Web API または Web アプリケーションの場合、応答 URL は、認証が成功した場合にトークンを含め、Azure AD が認証応答を送信する場所です。 ネイティブ アプリケーションの場合、リダイレクト URI は、Azure AD が OAuth 2.0 要求でユーザー エージェントをリダイレクトする一意の識別子です。
    • アプリケーション ID - アプリケーションの ID。アプリケーションの登録時に Azure AD によって生成されます。 認証コードまたはトークンを要求すると、認証時にアプリケーション ID とキーが Azure AD に送信されます。
    • キー - Web API を呼び出すために Azure AD に認証するときにアプリケーション ID と共に送信されるキー。

  • Azure AD では、ディレクトリ データや組織内の他のアプリケーションなどにアクセスするために必要なアクセス許可がアプリケーションに付与されていることを確認する必要があります。

詳細については、アプリの登録方法を参照してください。

シングルテナント アプリとマルチテナント アプリ

Azure AD と開発および統合できるアプリケーションには、次の 2 つのカテゴリがあることを理解すると、プロビジョニングがより明確になります。

  • シングル テナント アプリケーション - 1 つのテナント アプリケーションは、1 つの組織で使用することを目的としています。 これらは通常、エンタープライズ開発者によって記述された基幹業務 (LoB) アプリケーションです。 シングル テナント アプリケーションには、1 つのディレクトリ内のユーザーのみがアクセスする必要があり、その結果、1 つのディレクトリにのみプロビジョニングする必要があります。 通常、これらのアプリケーションは組織内の開発者によって登録されます。
  • マルチテナント アプリケーション - マルチテナント アプリケーションは、1 つの組織だけでなく、多くの組織で使用することを目的としています。 通常、これらは独立系ソフトウェア ベンダー (ISV) によって作成された SaaS (サービスとしてのソフトウェア) アプリケーションです。 マルチテナント アプリケーションは、使用される各ディレクトリにプロビジョニングする必要があります。これには、ユーザーまたは管理者が登録に同意する必要があります。 この同意プロセスは、アプリケーションをディレクトリに登録し、Graph API または別の Web API へのアクセス権を付与するときに開始されます。 別の組織のユーザーまたは管理者がアプリケーションを使用するためにサインアップすると、アプリケーションに必要なアクセス許可を表示するダイアログが表示されます。 その後、ユーザーまたは管理者はアプリケーションに同意できます。これにより、アプリケーションは指定されたデータにアクセスでき、最後にアプリケーションがディレクトリに登録されます。 詳細については、「 同意フレームワークの概要」を参照してください。

シングル テナントまたはマルチテナント アプリを開発するときの追加の考慮事項

シングル テナント アプリケーションではなくマルチテナント アプリケーションを開発する場合は、追加の考慮事項が発生します。 たとえば、複数のディレクトリ内のユーザーがアプリケーションを使用できるようにする場合は、アプリケーションが存在するテナントを特定するメカニズムが必要です。 シングル テナント アプリケーションでは、ユーザーの独自のディレクトリのみを検索する必要があります。マルチテナント アプリケーションでは、Azure AD 内のすべてのディレクトリから特定のユーザーを識別する必要があります。 このタスクを実行するために、Azure AD には、テナント固有のエンドポイントではなく、マルチテナント アプリケーションがサインイン要求を送信できる共通の認証エンドポイントが用意されています。 このエンドポイントは Azure AD 内のすべてのディレクトリに対して https://login.microsoftonline.com/common されますが、テナント固有のエンドポイントは https://login.microsoftonline.com/contoso.onmicrosoft.com可能性があります。 サインイン、サインアウト、トークンの検証中に複数のテナントを処理するために必要なロジックが必要になるため、アプリケーションを開発する際に特に考慮する必要がある共通エンドポイントは重要です。

現在シングル テナント アプリケーションを開発しているが、多くの組織で使用できるようにする場合は、Azure AD でアプリケーションとその構成を簡単に変更して、マルチテナント対応にすることができます。 さらに、Azure AD では、1 つのテナントまたはマルチテナント アプリケーションで認証を提供するかどうかにかかわらず、すべてのディレクトリ内のすべてのトークンに同じ署名キーが使用されます。

このドキュメントに記載されている各シナリオには、そのプロビジョニング要件について説明するサブセクションが含まれています。 Azure AD でのアプリケーションのプロビジョニングと、シングル テナント アプリケーションとマルチテナント アプリケーションの違いの詳細については、「 アプリケーションと Azure Active Directory の統合 」を参照してください。 引き続き、Azure AD の一般的なアプリケーション シナリオを理解してください。

次のステップ

  • Last updated on