Delegated permissions are used when the application is acting on behalf of a signed-in user. For example, if a user logs in and the app reads their own calendar or emails, delegated access is required.
Application permissions are used when the app needs to access data directly without a user being signed in. For instance, a background service that pulls calendar or meeting data for all users in an organization would require application permissions.Note: For some application permissions, such as accessing Teams meeting recordings, it is necessary to create an application access policy. (
https://learn.microsoft.com/en-us/graph/cloud-communication-online-meeting-application-access-policy)If you are using a company account instead of a personal account, you can complete all the steps up to this point. However, after adding the required permissions, an admin must grant consent for the application.With these steps, we can successfully start a Graph API application on Azure, but to access graph API app and use it, there are a few essential elements that are required. First, a
client secret must be created in the
Certificates & Secrets section of the app registration. This secret key acts as the main credential for your application to authenticate with Microsoft Graph, and it is crucial to store it securely, as it plays a central role in the security of your application.In addition to the client secret, the
Application (Client) ID and
Tenant ID can be found in the
Overview section of the app registration. The Application ID uniquely identifies your app, while the Tenant ID specifies the Azure AD tenant where the app is registered.Together, these three pieces of information the client secret, application ID, and tenant ID – allow your application to authenticate successfully and securely interact with Microsoft Graph API.