Register mobile apps that call web APIs
This article contains instructions to help you register a mobile application that you're creating.
Supported account types
The account types that your mobile applications support depend on the experience that you want to enable and the flows that you want to use.
Audience for interactive token acquisition
Most mobile applications use interactive authentication. If your app uses this form of authentication, you can sign in users from any account type.
Audience for integrated Windows authentication, username-password, and B2C
If you have a Universal Windows Platform (UWP) app, you can use integrated Windows authentication (IWA) to sign in users. To use IWA or username-password authentication, your application needs to sign in users in your own line-of-business (LOB) developer tenant. In an independent software vendor (ISV) scenario, your application can sign in users in Azure Active Directory organizations. These authentication flows aren't supported for Microsoft personal accounts.
You can also sign in users by using social identities that pass a B2C authority and policy. To use this method, you can use only interactive authentication and username-password authentication. Username-password authentication is currently supported only on Xamarin.iOS, Xamarin.Android, and UWP.
Platform configuration and redirect URIs
When you build a mobile app that uses interactive authentication, the most critical registration step is the redirect URI. You can set interactive authentication through the platform configuration on the Authentication blade.
This experience will enable your app to get single sign-on (SSO) through Microsoft Authenticator (and Intune Company Portal on Android). It will also support device management policies.
The app registration portal provides a preview experience to help you compute the brokered reply URI for iOS and Android applications:
In the app registration portal, select Authentication > Try out the new experience.
Select Add a platform.
When the list of platforms is supported, select iOS.
Enter your bundle ID, and then select Register.
When you complete the steps, the redirect URI is computed for you, as in the following image.
If you prefer to manually configure the redirect URI, you can do so through the application manifest. Here's the recommended format for the manifest:
- For example, enter
- For example, enter
- You can generate the Android signature hash by using the release key or debug key through the KeyTool command.
If your app uses only username-password authentication, you don't need to register a redirect URI for your application. This flow does a round trip to the Microsoft identity platform. Your application won't be called back on any specific URI.
However, identify your application as a public client application. To do so:
Still in the Azure portal, select your app in App registrations, and then select Authentication.
In Advanced settings > Allow public client flows > Enable the following mobile and desktop flows:, select Yes.
Mobile applications call APIs for the signed-in user. Your app needs to request delegated permissions. These permissions are also called scopes. Depending on the experience that you want, you can request delegated permissions statically through the Azure portal. Or you can request them dynamically at runtime.
By statically registering permissions, you allow administrators to easily approve your app. Static registration is recommended.
Move on to the next article in this scenario, App code configuration.