シナリオ:Web API を呼び出すデスクトップ アプリ

  • [アーティクル]

Web API を呼び出すデスクトップ アプリを構築するために必要なすべてのことについて説明します。

はじめに

初めてのアプリケーションをまだ作成していない場合、クイック スタートを完了して作成してください。

概要

デスクトップ アプリケーションを作成して、ユーザーをアプリケーションにサインインさせ、Microsoft Graph、他の Microsoft API、または独自の Web API などの Web API を呼び出します。 いくつかのオプションがあります。

  • 対話型トークン取得を使用できます。

    • ご利用のデスクトップ アプリケーションでグラフィカル コントロールがサポートされている場合 (たとえば、Windows.Form アプリケーション、Windows Presentation Foundation (WPF) アプリケーション、macOS ネイティブ アプリケーションなどの場合)。
    • または、.NET Core アプリケーションであり、システム ブラウザーで Microsoft Entra ID との認証のやり取りが発生することに同意している場合。
    • または、Chromium インスタンスで実行される Node.js Electron アプリケーションの場合。

  • Windows でホストされているアプリケーションの場合、Windows ドメインに参加しているコンピューター、または Microsoft Entra に参加しているコンピューターで実行されているアプリケーションが、統合 Windows 認証を使用して、確認を表示せずにトークンを取得することも可能です。

  • 最後に、推奨されていませんが、パブリック クライアント アプリケーションではユーザー名とパスワードを使用することができます。 DevOps などの一部のシナリオではまだこれが必要になります。 これを使用すると、アプリケーションに制約が発生します。 たとえば、多要素認証 (条件付きアクセス) を実行する必要があるユーザーはサインインさせることができません。 また、アプリケーションはシングル サインオン (SSO) のメリットを受けられません。

    さらに、先進認証の原則に反しており、これはレガシの理由のためにのみ提供されています。

    Desktop application

  • 移植可能なコマンド ライン ツール (おそらく、Linux または Mac で実行される .NET Core アプリケーション) を作成している場合、認証がシステム ブラウザーに委任されることに同意すると、対話式認証を使用できます。 .NET Core は Web ブラウザーを提供しないため、システム ブラウザーで認証が行われます。 それ以外の場合、そのケースの最善の選択肢は、デバイス コード フローを使用することです。 このフローは、Internet of Things (IoT) アプリケーションなどのブラウザーがないアプリケーションにも使用されます。

    Browserless application

詳細

デスクトップ アプリケーションには、いくつかの特異性があります。 これらは主に、アプリケーションが対話型認証を使用するかどうかによって異なります。

OAuth 2.0 と OpenID Connect を使用した ID およびアクセス管理 (IAM) を初めて使用する場合、または Microsoft ID プラットフォームの IAM を初めて使用する場合は、次の一連の記事をお読みください。

これらは、最初のクイックスタートまたはチュートリアルを完了する前に読む必要はありませんが、プラットフォームに不可欠なトピックについて説明しており、これらをよく知ると、より複雑なシナリオを構築する際に役立ちます。

認証と権限承認

Microsoft ID プラットフォーム

次のステップ

このシナリオの次の記事「アプリの登録」に進みます。