Scenario: Desktop app that calls web APIs
Learn all you need to build a desktop app that calls web APIs.
If you haven't already, create your first application by completing a quickstart:
- Quickstart: Acquire a token and call Microsoft Graph API from a Windows desktop app
- Quickstart: Acquire a token and call Microsoft Graph API from a UWP app
- Quickstart: Acquire a token and call Microsoft Graph API from a macOS native app
- Quickstart: Acquire a token and call Microsoft Graph API from a Node.js & Electron app
You write a desktop application, and you want to sign in users to your application and call web APIs such as Microsoft Graph, other Microsoft APIs, or your own web API. You have several options:
You can use the interactive token acquisition:
- If your desktop application supports graphical controls, for instance, if it's a Windows.Form application, a WPF application, or a macOS native application.
- Or, if it's a .NET Core application and you agree to have the authentication interaction with Azure Active Directory (Azure AD) happen in the system browser.
- Or, if it's a Node.js Electron application, which runs on a Chromium instance.
For Windows hosted applications, it's also possible for applications running on computers joined to a Windows domain or Azure AD joined to acquire a token silently by using integrated Windows authentication.
Finally, and although it's not recommended, you can use a username and a password in public client applications. It's still needed in some scenarios like DevOps. Using it imposes constraints on your application. For instance, it can't sign in a user who needs to perform multi-factor authentication (conditional access). Also, your application won't benefit from single sign-on (SSO).
It's also against the principles of modern authentication and is only provided for legacy reasons.
If you write a portable command-line tool, probably a .NET Core application that runs on Linux or Mac, and if you accept that authentication will be delegated to the system browser, you can use interactive authentication. .NET Core doesn't provide a web browser, so authentication happens in the system browser. Otherwise, the best option in that case is to use device code flow. This flow is also used for applications without a browser, such as IoT applications.
Desktop applications have a number of specificities. They depend mainly on whether your application uses interactive authentication or not.
If you're new to identity and access management (IAM) with OAuth 2.0 and OpenID Connect, or even just new to IAM on the Microsoft identity platform, the following set of articles should be high on your reading list.
Although not required reading before completing your first quickstart or tutorial, they cover topics integral to the platform, and familiarity with them will help you on your path as you build more complex scenarios.
Move on to the next article in this scenario, App registration.