They may also need to access web APIs such as the Microsoft Graph API (to access Azure Active Directory, Intune, and services in Office 365) and other Microsoft services' APIs, in addition to your own web APIs.
This section describes various ways in which you can configure your application further.
First we start with an overview of the consent framework, which is important to understand when building applications that need to be used by other users or applications.
The Azure AD consent framework makes it easy to develop multi-tenant web and native client applications, including multi-tier applications.
These applications allow sign-in by user accounts from an Azure AD tenant, different from the one where the application is registered.
This registration process involves giving Azure AD details about your application, such as the URL where it’s located, the URL to send replies after a user is authenticated, the URI that identifies the app, and so on.
Once your application has been registered with Azure AD, it may need to be updated to provide access to web APIs, be made available in other organizations, and more.
The application manifest actually serves as a mechanism for updating the Application entity, which defines all attributes of an Azure AD application's identity configuration, including the API access scopes we discussed.
For more information on the Application entity and its schema, see the Graph API Application entity documentation.
Access scopes and roles are exposed through your application's manifest, which is a JSON file that represents your application’s identity configuration.