Edit

Share via

Desktop app that calls web APIs: App registration

  • Article

Applies to: Green circle with a white check mark symbol. Workforce tenants White circle with a gray X symbol. External tenants (learn more)

This article covers the app registration specifics for a desktop application.

Supported account types

The account types supported in a desktop application depend on the experience that you want to light up. Because of this relationship, the supported account types depend on the flows that you want to use.

Audience for interactive token acquisition

If your desktop application uses interactive authentication, you can sign in users from any account type.

Audience for desktop app silent flows

  • To use integrated Windows authentication or a username and a password, your application needs to sign in users in your own tenant, for example, if you're a line-of-business (LOB) developer. Or, in Microsoft Entra organizations, your application needs to sign in users in your own tenant if it's an ISV scenario. These authentication flows aren't supported for Microsoft personal accounts.
  • If you sign in users with social identities that pass a business-to-commerce (B2C) authority and policy, you can only use the interactive and username-password authentication.

Redirect URIs

The redirect URIs to use in a desktop application depend on the flow you want to use.

Specify the redirect URI for your app by configuring the platform settings for the app in App registrations in the Microsoft Entra admin center.

  • For apps that use Web Authentication Manager (WAM), redirect URIs need not be configured in MSAL, but they must be configured in the app registration.

  • For apps that use interactive authentication:

    • Apps that use embedded browsers: https://login.microsoftonline.com/common/oauth2/nativeclient (Note: If your app would pop up a window which typically contains no address bar, it is using the "embedded browser".)
    • Apps that use system browsers: http://localhost (Note: If your app would bring your system's default browser (such as Edge, Chrome, Firefox, and so on) to visit Microsoft login portal, it is using the "system browser".)

    Important

    As a security best practice, we recommend explicitly setting https://login.microsoftonline.com/common/oauth2/nativeclient or http://localhost as the redirect URI. Some authentication libraries like MSAL.NET use a default value of urn:ietf:wg:oauth:2.0:oob when no other redirect URI is specified, which is not recommended. This default will be updated as a breaking change in the next major release.

  • If you build a native Objective-C or Swift app for macOS, register the redirect URI based on your application's bundle identifier in the following format: msauth.<your.app.bundle.id>://auth. Replace <your.app.bundle.id> with your application's bundle identifier.

  • If you build a Node.js Electron app, use a custom string protocol instead of a regular web (https://) redirect URI in order to handle the redirection step of the authorization flow, for instance msal{Your_Application/Client_Id}://auth (such as msal00001111-aaaa-2222-bbbb-3333cccc4444://auth). The custom string protocol name shouldn't be obvious to guess and should follow the suggestions in the OAuth2.0 specification for Native Apps.

  • If your app uses only integrated Windows authentication or a username and a password, you don't need to register a redirect URI for your application. These flows do a round trip to the Microsoft identity platform v2.0 endpoint. Your application won't be called back on any specific URI.

  • To distinguish device code flow, integrated Windows authentication, and a username and a password from a confidential client application using a client credential flow used in daemon applications, none of which requires a redirect URI, configure it as a public client application. To achieve this configuration:

    1. In the Microsoft Entra admin center, select your app in App registrations, and then select Authentication.

    2. In Advanced settings > Allow public client flows > Enable the following mobile and desktop flows:, select Yes.

      Enable public client setting on Authentication pane in Azure portal

API permissions

Desktop applications call APIs for the signed-in user. They need to request delegated permissions. They can't request application permissions, which are handled only in daemon applications.

Next steps

Move on to the next article in this scenario, App Code configuration.