
Getting to the end, slowly but surely. In this section covering the following:
- plan your line of business application registration strategy
- implement application registrations
- configure application permissions
- implement application authorization
- plan and configure multi-tier application permissions
Table of Contents
What is App registration in Azure?
With App registration You can register any application to Your tenant and provide authentication and authorization for that application.
When you create an application, you allow trust to be established between the application and the Microsoft identity platform. This trust is only unidirectional, the application trusts Microsoft platform but Microsoft platform doesn’t trust the app.
Plan your line of business application registration strategy
Why do applications integrate with Azure AD?
Add applications to Azure AD to leverage one or more of the services it provides, including:
- Application authentication and authorization.
- User authentication and authorization.
- Single sign-on (SSO) using federation or password.
- User provisioning and synchronization.
- Role-based access control: Use the directory to define application roles to perform role-based authorization checks in an application.
- OAuth authorization services: Used by Microsoft 365 and other Microsoft applications to authorize access to APIs/resources.
- Application publishing and proxy: Publish an application from a private network to the internet.
- Directory schema extension attributes: Extend the schema of service principal and user objects to store additional data in Azure AD.
Who can sign in to your app?

What are service principals and where do they come from?
You can manage service principals in the Azure portal through the Enterprise Applications experience. Service principals govern an application connecting to Azure AD and can be considered the instance of the application in your directory. Any given application can have at most one application object (which is registered in a “home” directory) and one or more service principal objects representing instances of the application in every directory in which it acts.
What are application objects and where do they come from?
You can manage application objects in the Azure portal through the App Registrations experience. Application objects define and describe the application to Azure AD, enabling Azure AD to know how to issue tokens to the application based on its settings. The application object will only exist in its home directory, even if it’s a multi-tenant application supporting service principals in other directories.
Prerequisites
- An Azure account that has an active subscription. Create an account for free.
- The Azure account must have permission to manage applications in Azure Active Directory (Azure AD). Any of the following Azure AD roles include the required permissions:
Licensing
Free and basic Azure AD pricing tiers allow You to register 10 applications.
Azure AD Premium 1 and 2 allows registering unlimited apps per user.
Tenants to choose from
The app can be registered inside Azure AD and You have the tenant options.
- Work and school (Azure AD) accounts or Microsoft accounts (such as Outlook.com and Live.com)
- Social and local (Azure AD B2C) accounts
Limitations
- A maximum of 100 users and service principals can be owners of a single application.
- A user, group, or service principal can have a maximum of 1,500 app role assignments. The limitation is on the service principal, user, or group across all app roles and not on the number of assignments on a single app role.
- An app configured for password-based single sign-on can have a maximum of 48 groups assigned with credentials configured.
- A user can have credentials configured for a maximum of 48 apps using password-based single sign-on. This limit only applies for credentials configured when the user is directly assigned the app, not when the user is a member of a group which is assigned.
- A maximum of 1,200 entries can be added to the application manifest.
Validation differences by supported account types
When registering an application with the Microsoft identity platform for developers, you’re asked to select which account types your application supports. In the application object and manifest, this property is signInAudience
.
The options include the following values:
- AzureADMyOrg: Only accounts in the organizational directory where the app is registered (single-tenant).
- AzureADMultipleOrgs: Accounts in any organizational directory (multi-tenant).
- AzureADandPersonalMicrosoftAccount: Accounts in any organizational directory (multi-tenant) and personal Microsoft accounts (for example, Skype, Xbox, and Outlook.com)
Validation differences for different property’s
Property | AzureAD MyOrg | AzureAD Multiple Orgs | AzureAD PersonalMicrosoftAccount and Personal MicrosoftAccount |
---|---|---|---|
Application ID URI (identifierURIs ) | Must be unique in the tenant urn:// schemes are supported Wildcards aren’t supported Query strings and fragments are supported Maximum length of 255 characters No limit* on number of identifierURIs | Must be globally unique urn:// schemes are supported Wildcards aren’t supported Query strings and fragments are supported Maximum length of 255 characters No limit* on number of identifierURIs | Must be globally unique urn:// schemes aren’t supported Wildcards, fragments, and query strings aren’t supported Maximum length of 120 characters Maximum of 50 identifierURIs |
Certificates (keyCredentials ) | Symmetric signing key | Symmetric signing key | Encryption and asymmetric signing key |
Client secrets (passwordCredentials ) | No limit* | No limit* | If liveSDK is enabled: Maximum of two client secrets |
Redirect URIs (replyURLs ) | See Redirect URI/reply URL restrictions and limitations for more info. | ||
API permissions (requiredResourceAccess ) | No more than 50 APIs (resource apps) from the same tenant as the application, no more than 10 APIs from other tenants, and no more than 400 permissions total across all APIs. | No more than 50 APIs (resource apps) from the same tenant as the application, no more than 10 APIs from other tenants, and no more than 400 permissions total across all APIs. | Maximum of 50 resources per application and 30 permissions per resource (for example, Microsoft Graph). Total limit of 200 per application (resources x permissions). |
Scopes defined by this API (oauth2Permissions ) | Maximum scope name length of 120 characters No limit* on the number of scopes defined | Maximum scope name length of 120 characters No limit* on the number of scopes defined | Maximum scope name length of 40 characters Maximum of 100 scopes defined |
Authorized client applications (preAuthorizedApplications ) | No limit* | No limit* | Total maximum of 500 Maximum of 100 client apps defined Maximum of 30 scopes defined per client |
appRoles | Supported No limit* | Supported No limit* | Not supported |
Front-channel logout URL | https://localhost is allowedhttp scheme isn’t allowedMaximum length of 255 characters | https://localhost is allowedhttp scheme isn’t allowedMaximum length of 255 characters | https://localhost is allowed, http://localhost failshttp scheme isn’t allowedMaximum length of 255 characters Wildcards aren’t supported |
Display name | Maximum length of 120 characters | Maximum length of 120 characters | Maximum length of 90 characters |
Tags | Individual tag size must be between 1 and 256 characters (inclusive) No whitespaces or duplicate tags allowed No limit* on number of tags | Individual tag size must be between 1 and 256 characters (inclusive) No whitespaces or duplicate tags allowed No limit* on number of tags | Individual tag size must be between 1 and 256 characters (inclusive) No whitespaces or duplicate tags allowed No limit* on number of tags |
Implement application registrations
Search for App registration

In this page You can register the application or show Your own endpoints that can be used for connecting to Your published applications.

When You create an application You can choose from different options.

These are supported account types that You can use. If You want to publish the app to Your own users, choose “In this directory only” and if You want to allow any external users, select “Any organizational directory.
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 app is a single-tenant application in the Microsoft identity platform. |
Accounts in any organizational directory | Select this option if you want users in any Azure Active Directory (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 type of app is known as a multitenant 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 multitenant application that can also support users who have personal Microsoft accounts. |
Personal Microsoft accounts | Select this option if you’re building an application only for users who have personal Microsoft accounts. Personal Microsoft accounts include Skype, Xbox, Live, and Hotmail |
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://cloudpartnerdemo.fi/auth-response
. During development, it’s common to also add the endpoint where you run your app locally, like https://127.0.0.1/auth-response
or http://localhost/auth-response
.
So now You app could look like this.

Configure application permissions
App scope
In the Expose and API You can add permissions for the application.

Application ID URI
The App ID URI acts as the prefix for the scopes you’ll reference in your API’s code, and it must be globally unique. You can use the default value provided, which is in the form api://<application-client-id>
, or specify a more readable URI like https://cloudpartnerdemo.fi/api
.


Add a scope
From add a scope You can add permissions and who can consent to the permissions. Default is Admin only.

Once created, the scope will show in the page.

Client app
Next You will create a Client Demo app, This app will connect to the DemoApp we created in the earlier steps.
Then API permissions and Add a permissions

Go to My APIs to find the API we created in the earlier steps.

And You will see the Exposed permissions we created.

But You will see there is no consent for the app, click Grant admin consent

And select yes

ut if You don’t have Admin rights the Grant admin consent button is disabled if you aren’t an admin or if no permissions have been configured for the application. If you have permissions that have been granted but not yet configured, the admin consent button prompts you to handle these permissions. You can add them to configured permissions or remove them.
Platforms
Depending on the platform or device this application is targeting, additional configuration may be required such as redirect URIs, specific authentication settings, or fields specific to the platform.

Platform | Configuration settings |
---|---|
Web | Enter a Redirect URI for your app. This URI is the location where the 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. This URI is the location where the Microsoft identity platform redirects a user’s client and sends security tokens after authentication. Select this platform if you’re building a client-side web app by using JavaScript or a framework like Angular, Vue.js, React.js, or Blazor WebAssembly. |
iOS / macOS | Enter the app Bundle ID. Find it in Build Settings or in Xcode in Info.plist. A redirect URI is generated for you when you specify a Bundle ID. |
Android | Enter the app Package name. Find it in the AndroidManifest.xml file. Also 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 using embedded browser, we recommend https://login.microsoftonline.com/common/oauth2/nativeclient For desktop applications using system browser, we recommend http://localhost Select this platform for mobile applications that aren’t using the latest Microsoft Authentication Library (MSAL) or aren’t using a broker. Also select this platform for desktop applications. |
Microsoft Graph
If You go browse App a permission again, You will see lot’s of different APIs. From here You could add permissions for Microsoft Graph.

You have to options to add permissions.

Implement application authorization
Manifest
You can see the config that we just created in the manifest as JSON. You can download, edit it and upload to a different App or just as backup.

What is a Manifest?
With manifest you can manipulate the attributes sent to destination app. There is a json-file that you can edit.
NewGuid
But first you need and Unique GUID, doesn’t have to be anything considering your app, just unique.
You can create a unique GUID with powershell
[guid]::NewGuid()
or if you prefer to use GUID generator from the web, just search, there is a lot of them.
So, GUID looks like this.

App registrations
And every single time you generate new it will be different. Then you go to Azure Active Directory and choose App registrations.

And your freshly configured app.

And Manifest.

Under manifest you find the json file, I like to edit json’s in Visual Studio Code as you lot’s of plugins to provide the necessary support for whatever you are editing.
If you mess up your json, there is no turning back so download it first so you have an backup.

AppRoles
Copy paste to Visual Studio and find the part that says AppRoles

In the AppRoles copy one block and modify based on your needs.
In my demo I created a role called Demo_Role and here is the part you need the Unique GUID

And also add your wanted role to Value field like above.
Then copy paste the json back to online editor and save. If the modification are correct, you will get a popup saying

AppRoles from GUI
When you open App registration, you will find App roles under it.
Allowed member types specifies whether this app role can be assigned to users and groups by setting to ‘User/Groups’, or to other applications by setting to ‘Application’, or to both.
Value specifies which will be included in the “roles” claim of a token identifying a user or app which has been granted this app role

You can easily find the different values for the app roles from Microsoft Graph.
For Delegated permissions

For Application permissions

Assign roles and users
Then go backup Enterprise applications and find your app.
And choose Assign user and Roles.

Choose Add user / Group and find the user or group that you need to assign the app role.
Note! Nested groups cannot be used, but dynamic groups will work.
Certificates or secrets?
You can use a certificates, client secret or Federated credentials (OpenID Connect)
I will go with secrets. You can create secret which will last up-to 24months but Microsoft recommends the maximum to be 12months.


Now is the only time You can copy the secret You just created, after this one it isn’t possible.

Application and object ID
In the overview page You can find Your App and Object ID’s, these are the one that Your software will connect to the apps.


Customizing App
In the Branding & properties You can find the logo and name that will be provided in the MyApps portal and External Azure Enterprise Applications collection.
You can also update Your custom domain here, if any and add Publisher verification.
Publisher verification has to be the Microsoft Partner Network ID that have the same domain than the Custom Domain in the Publisher domain has.

Plan and configure multi-tier application permissions
Multi-tenant app means that user logon to https://login.microsoftonline.com and not to a specific Tenant.
With a multi-tenant application, the application doesn’t know up front what tenant the user is from, so you can’t send requests to a tenant’s endpoint. Instead, requests are sent to an endpoint that multiplexes across all Azure AD tenants: https://login.microsoftonline.com/common
When the Microsoft identity platform receives a request on the /common endpoint, it signs the user in and, as a consequence, discovers which tenant the user is from. The /common endpoint works with all of the authentication protocols supported by the Azure AD: OpenID Connect, OAuth 2.0, SAML 2.0, and WS-Federation.
The sign-in response to the application then contains a token representing the user. The issuer value in the token tells an application what tenant the user is from. When a response returns from the /common endpoint, the issuer value in the token corresponds to the user’s tenant.
When You create a multi-tenant app, you simply choose Multitenant from the app registration.

When the app is created, you can still change the type from here.


On-Behalf-Of flow (OBO)
OAuth 2.0 On-Behalf-Of-Flow (OBO) provides a use case where an application needs to call a service / Web API and then another service / Web API. The idea is to propagate the delegated user ID and permissions to the request chain. In order for the middle tier service to send authenticated requests to downstream services, it must protect the access token from the Microsoft ID platform on behalf of the user.

- The client application makes a request to API A with token A (with an
aud
claim of API A). - API A authenticates to the Microsoft identity platform token issuance endpoint and requests a token to access API B.
- The Microsoft identity platform token issuance endpoint validates API A’s credentials along with token A and issues the access token for API B (token B) to API A.
- Token B is set by API A in the authorization header of the request to API B.
- Data from the secured resource is returned by API B to API A, then to the client.
Things to remember
Free and Basic Azure offers have a limit of 10 apps per user. Azure P1 and P2 don’t have any limit.
Web API has Exposed API and the client have API permissions.
Differences between Application and Object ID:
An app registration in Azure AD results in an Application object. All objects in Azure AD have an object ID. When you making an API request to address a specific Application object, you would use the object ID:
An Application object’s object ID is only relevant in the same tenant where the app is registered, and is only ever used to identify that object.
AppRoles can be defined in Manifest or thru the portal.
An Application objects Application ID attribute is used used across tenants, and on more than one object type. There are two primary uses:
- To identify the app in various sign-in and token flows (e.g.
client_id
in OAuth 2.0 and OpenID Connect). - To uniquely identify the backing Application object of a ServicePrincipal object. (Think of the ServicePrincipal object as the “instance” of the app in a given Azure AD tenant.)
Limitations
- A maximum of 100 users and service principals can be owners of a single application.
- A user, group, or service principal can have a maximum of 1,500 app role assignments. The limitation is on the service principal, user, or group across all app roles and not on the number of assignments on a single app role.
- An app configured for password-based single sign-on can have a maximum of 48 groups assigned with credentials configured.
- A user can have credentials configured for a maximum of 48 apps using password-based single sign-on. This limit only applies for credentials configured when the user is directly assigned the app, not when the user is a member of a group which is assigned.
- A maximum of 1,200 entries can be added to the application manifest.
Different platform options.
Multi-tenant app logins the user to https://login.microsoftonline.com and the requests go to https://login.microsoftonline.com/common
Understand the different Microsoft identity platform concepts. https://docs.microsoft.com/en-us/azure/active-directory/develop/developer-glossary