案例:呼叫 Web API 的傳統型應用程式

了解建置可呼叫 Web API 的傳統型應用程式所需的一切。

開始使用

如果您還沒有進行此操作,請完成快速入門以建立您的第一個應用程式:

概觀

您撰寫傳統型應用程式,而且想要讓使用者登入您的應用程式,並呼叫 Web API (例如 Microsoft Graph)、其他 Microsoft API 或您自己的 Web API。 您有幾種選項:

  • 在下列情況,您可使用互動式權杖取得:

    • 如果您的傳統型應用程式支援圖形化控制項,例如,若是 Windows Form 應用程式、Windows Presentation Foundation (WPF) 應用程式或 macOS 原生應用程式。
    • 或者,若是 .NET Core 應用程式,而且您同意與系統瀏覽器中的 Azure Active Directory (Azure AD) 進行驗證互動。
    • 或者,如果是在 Chromium 執行個體上執行的 Node.js Electron 應用程式。
  • 若為 Windows 裝載的應用程式,在已加入 Windows 網域或已加入 Azure AD 的電腦上執行的應用程式,也可使用整合式 Windows 驗證以無訊息方式取得權杖。

  • 最後,雖然不建議這麼做,但您可在公用用戶端應用程式中使用使用者名稱和密碼。 在某些案例 (例如 DevOps) 中,仍然需要這麼做。 這麼做會對您的應用程式施加條件約束。 例如,這麼做無法讓需要執行多重要素驗證 (條件式存取) 的使用者登入。 此外,您的應用程式也不會受益於單一登入 (SSO)。

    它也違反了新式驗證的原則,僅供舊版的理由之用。

    Desktop application

  • 如果您撰寫可攜式命令列工具 (可能是在 Linux 或 Mac 上執行的 .NET Core 應用程式),而且若接受將驗證委派給系統瀏覽器,則可使用互動式驗證。 .NET Core 不會提供網頁瀏覽器,因此會在系統瀏覽器中進行驗證。 否則,在該情況下,最佳選項是使用裝置碼流程。 此流程也會用於沒有瀏覽器的應用程式,例如物聯網 (IoT) 應用程式。

    Browserless application

特性

桌面應用程式有幾個特例。 其主要取決於您的應用程式是否使用互動式驗證。

若您不熟悉使用 OAuth 2.0 與 OpenID Connect 的身分識別與存取管理 (IAM),或甚至第一次使用 Microsoft 身分識別平台上的 IAM,則應將下列文章集優先加入您的閱讀清單。

雖然在完成您的第一個快速入門或教學課程之前不需要閱讀,但這些文章涵蓋平台不可或缺的主題,而且熟悉這些主題將可在建置更複雜的案例時,協助您順利進行。

Microsoft 身分識別平台

後續步驟

移至此案例的下一篇文章,應用程式註冊