Quickstart: Register an application with the Microsoft identity platform
In this quickstart, you register an app in the Azure portal so the Microsoft identity platform can provide authentication and authorization services for your application and its users.
Each application you want the Microsoft identity platform to perform identity and access management (IAM) for needs to be registered. Whether it's a client application like a web or mobile app, or it's a web API that backs a client app, registering it establishes a trust relationship between your application and the identity provider, the Microsoft identity platform.
- An Azure account with an active subscription - create an account for free
- Completion of Quickstart: Set up a tenant
Register an application
Registering your application establishes a trust relationship between your app and the Microsoft identity platform. The trust is unidirectional: your app trusts the Microsoft identity platform, and not the other way around.
Follow these steps to create the app registration:
Sign in to the Azure portal.
If you have access to multiple tenants, use the Directory + subscription filter in the top menu to select the tenant in which you want to register an application.
Search for and select Azure Active Directory.
Under Manage, select App registrations > New registration.
Enter a Name for your application. Users of your app might see this name, and you can change it later.
Specify who can use the application, sometimes referred to as the sign-in audience.
Supported account types Description Accounts in this organizational directory only Select this option if you're building an application for use only by users (or guests) in your tenant.
Often called a line-of-business (LOB) application, this is a single-tenant application in the Microsoft identity platform.
Accounts in any organizational directory Select this option if you'd like users in any Azure AD tenant to be able to use your application. This option is appropriate if, for example, you're building a software-as-a-service (SaaS) application that you intend to provide to multiple organizations.
This is known as a multi-tenant application in the Microsoft identity platform.
Accounts in any organizational directory and personal Microsoft accounts Select this option to target the widest set of customers.
By selecting this option, you're registering a multi-tenant application that can also support users with personal Microsoft accounts (MSA).
Personal Microsoft accounts Select this option if you're building an application for use only by users with personal Microsoft accounts. Personal Microsoft accounts include Skype, Xbox, Live, and Hotmail accounts.
Don't enter anything for Redirect URI (optional), you'll configure one in the next section.
Select Register to complete the initial app registration.
When registration completes, the Azure portal displays the app registration's Overview pane, which includes its Application (client) ID. Also referred to as just client ID, this value uniquely identifies your application in the Microsoft identity platform.
Your application's code, or more typically an authentication library used in your application, also uses the client ID as one aspect in validating the security tokens it receives from the identity platform.
Add a redirect URI
A redirect URI is the location where the Microsoft identity platform redirects a user's client and sends security tokens after authentication.
In a production web application, for example, the redirect URI is often a public endpoint where your app is running, like
https://contoso.com/auth-response. During development, it's common to also add the endpoint where you run your app locally, like
You add and modify redirect URIs for your registered applications by configuring their platform settings.
Configure platform settings
Settings for each application type, including redirect URIs, are configured in Platform configurations in the Azure portal. Some platforms, like Web and Single-page applications, require you to manually specify a redirect URI. For other platforms like mobile and desktop, you can select from redirect URIs generated for you when you configure their other settings.
To configure application settings based on the platform or device you're targeting:
Select your application in App registrations in the Azure portal.
Under Manage, select Authentication.
Under Platform configurations, select Add a platform.
In Configure platforms, select the tile for your application type (platform) to configure its settings.
Platform Configuration settings Web Enter a Redirect URI for your app, the location where Microsoft identity platform redirects a user's client and sends security tokens after authentication.
Select this platform for standard web applications that run on a server.
Single-page application Enter a Redirect URI for your app, the location where Microsoft identity platform redirects a user's client and sends security tokens after authentication.
iOS / macOS Enter the app Bundle ID, found in XCode in Info.plist or Build Settings.
A redirect URI is generated for you when you specify a Bundle ID.
Android Enter the app Package name, which you can find in the AndroidManifest.xml file, and generate and enter the Signature hash.
A redirect URI is generated for you when you specify these settings.
Mobile and desktop applications Select one of the Suggested redirect URIs or specify a Custom redirect URI.
For desktop applications, we recommend:
Select this platform for mobile applications that aren't using the latest Microsoft Authentication Library (MSAL) or are not using a broker. Also select this platform for desktop applications.
Select Configure to complete the platform configuration.
Redirect URI restrictions
There are certain restrictions on the format of the redirect URIs you add to an app registration. For details on these restrictions, see Redirect URI (reply URL) restrictions and limitations.
Credentials are used by confidential client applications that access a web API. Examples of confidential clients are web apps, other web APIs, or service- and daemon-type applications. Credentials allow your application to authenticate as itself, requiring no interaction from a user at runtime.
You can add both certificates and client secrets (a string) as credentials to your confidential client app registration.
Add a certificate
Sometimes called a public key, certificates are the recommended credential type as they provide a higher level of assurance than a client secret. For more information on details about using certificate as an authentication method in your application , see Microsoft identity platform application authentication certificate credentials
- Select your application in App registrations in the Azure portal.
- Select Certificates & secrets > Upload certificate.
- Select the file you'd like to upload. It must be one of the following file types: .cer, .pem, .crt.
- Select Add.
Add a client secret
The client secret, known also as an application password, is a string value your app can use in place of a certificate to identity itself. It's the easier of the two credential types to use and is often used during development, but is considered less secure than a certificate. You should use certificates in your applications running in production. For more information on application security recommendations, please see Microsoft identity platform best practices and recommendations
- Select your application in App registrations in the Azure portal.
- Select Certificates & secrets > New client secret.
- Add a description for your client secret.
- Select a duration.
- Select Add.
- Record the secret's value for use in your client application code - it's never displayed again after you leave this page.
Note: The ID generated along with the secret's value is the ID of the secret, which is different than Application ID.
Client applications typically need to access resources in a web API. In addition to protecting your client application with the Microsoft identity platform, you can use the platform for authorizing scoped, permissions-based access to your web API.
Move on to the next quickstart in the series to create another app registration for your web API and expose its scopes.