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

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

開始使用

如果您還沒有這麼做,請完成快速入門以建立您的第一個應用程式:

概觀

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

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

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

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

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

    傳統型應用程式

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

    無瀏覽器應用程式

特性

傳統型應用程式有幾個特性。 其主要取決於您的應用程式是否使用互動式驗證。

如果您不熟悉身分識別和存取管理 (IAM) 與 OAuth 2.0 和 OpenID Connect,或甚至剛接觸到 Microsoft 身分識別平臺上的 IAM,則閱讀清單中的下列一組文章應該會很高。

雖然在完成您的第一個快速入門或教學課程之前不需要閱讀,但它們涵蓋了平臺不可或缺的主題,並熟悉這些主題將可在您建立更複雜的案例時,協助您在路徑上。

Microsoft 身分識別平台

下一步

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