次の方法で共有

Web API を呼び出すデスクトップ アプリ:アプリの登録

  • [アーティクル]

この記事では、デスクトップ アプリケーションのアプリ登録の詳細について説明しています。

サポートされているアカウントの種類

デスクトップ アプリケーションでサポートされるアカウントの種類は、利用するエクスペリエンスによって異なります。 この関係により、サポートされるアカウントの種類は、使用するフローによって決まります。

対話型トークン取得の対象ユーザー

デスクトップ アプリケーションで対話型認証を使用する場合は、任意のアカウントの種類からユーザーをサインインできます。

デスクトップ アプリのサイレント フローの対象ユーザー

  • 統合 Windows 認証またはユーザー名とパスワードを使用するには、たとえば、自分が基幹業務 (LOB) 開発者である場合、アプリケーションでは自分のテナントのユーザーをサインインする必要があります。 また、Microsoft Entra 組織では、ISV のシナリオの場合、アプリケーションでは自分のテナントのユーザーをサインインする必要があります。 これらの認証フローは、Microsoft の個人用アカウントではサポートされていません。
  • B2C (business-to-commerce) 機関とポリシーを渡すソーシャル ID を使用してユーザーをサインインする場合は、ユーザー名とパスワードの対話型認証のみを使用できます。

リダイレクト URI

デスクトップ アプリケーションで使用するリダイレクト URI は、使用するフローによって決まります。

Microsoft Entra 管理センターの [アプリの登録] でアプリのプラットフォーム設定を構成して、アプリのリダイレクト URI を指定します。

  • Web Authentication Manager (WAM) を使用するアプリケーションの場合、リダイレクト URI は MSAL で構成する必要はありませんが、アプリの登録で構成する必要があります。

  • 対話型認証を使用するアプリの場合:

    • 埋め込みブラウザーを使用するアプリ: https://login.microsoftonline.com/common/oauth2/nativeclient (注: アプリでポップアップ表示されるウィンドウに通常、アドレス バーが含まれていない場合、"埋め込みブラウザー" が使用されています)。
    • システム ブラウザーを使用するアプリ: http://localhost (注: アプリでシステムの既定のブラウザー (Edge、Chrome、Firefox など) が起動して Microsoft ログイン ポータルにアクセスする場合は、"システム ブラウザー" が使用されています。)

    重要

    セキュリティのベスト プラクティスとして、https://login.microsoftonline.com/common/oauth2/nativeclient または http://localhost をリダイレクト URI として明示的に設定することをお勧めします。 MSAL.NET のような一部の認証ライブラリでは、他のリダイレクト URI が指定されていない場合、推奨されていない既定値の urn:ietf:wg:oauth:2.0:oob が使用されます。 この既定値は、次のメジャー リリースで破壊的変更として更新されます。

  • macOS 用のネイティブ Objective-C または Swift アプリを構築する場合は、アプリケーションのバンドル識別子に基づいて、msauth.<your.app.bundle.id>://auth の形式でリダイレクト URI を登録します。 <your.app.bundle.id> をご使用のアプリケーションのバンドル ID に置き換えます。

  • Node.js Electron アプリを作成する場合は、認可フローのリダイレクト手順を処理するために、通常の web (https://) リダイレクト URI ではなくカスタム文字列プロトコル、たとえば msal{Your_Application/Client_Id}://auth を使用します (例: msal00001111-aaaa-2222-bbbb-3333cccc4444://auth)。 カスタム文字列プロトコル名はすぐに推測できるものにすべきではなく、ネイティブ アプリに関する OAuth 2.0 仕様に記載されている勧告に従う必要があります。

  • アプリで統合 Windows 認証またはユーザー名とパスワードのみを使用する場合は、アプリケーションのリダイレクト URI を登録する必要はありません。 これらのフローは、Microsoft ID プラットフォーム v2.0 エンドポイントへのラウンドトリップを実行します。 アプリケーションが特定の URI でコールバックされることはありません。

  • デバイス コード フロー、統合 Windows 認証、およびユーザー名とパスワードを、リダイレクト URI を必要としないデーモン アプリケーションで使用されるクライアント資格証明フローを使用した機密クライアント アプリケーションと区別するには、それをパブリック クライアント アプリケーションとして構成します。 この構成を実現するには:

    1. Microsoft Entra 管理センターで、[アプリの登録] でアプリを選択し、[認証] を選択します。

    2. [詳細設定]>[Allow public client flows]\(パブリック クライアント フローを許可する\)>[Enable the following mobile and desktop flows:]\(次のモバイルとデスクトップのフローを有効にする\) で [はい] を選択します。

      Azure portal の [認証] ウィンドウでパブリック クライアント設定を有効にする

API のアクセス許可

デスクトップ アプリケーションは、サインインしたユーザーのために API を呼び出します。 委任されたアクセス許可を要求する必要があります。 アプリケーションのアクセス許可を要求することはできません。これは、デーモン アプリケーションでのみ処理されます。

次の手順

このシナリオの次の記事であるアプリ コードの構成に関する記事に進みます。