After installing Calendar App you can use it for all SharePoint data sources from current Site Collection without additional prompt to install Calendar Authorization App.

If you setup your calendar to use Exchange calendars or SharePoint data sources you may be prompted to install Calendar Authorization App.


To overlay Calendars from different Site Collections and (or) Calendars, Meeting Rooms from Exchange Online, you need to register Calendar Authorization App in your Azure Active Directory.


Calendar Authorization App needs to be registered in Azure Active Directory in the context of your tenant. Before a trusted application can be used in the tenant, tenant consent is required. Calendar Authorization App permission requests must be consented to by the tenant's admin account.



Your tenant admin should mark checkbox "Consent on behalf of your organization".


Once it will be accepted, the Calendar Authorization App can get oauth tokens from AAD, for that tenant and display Calendars from Exchange Online or other Site Collections.

Once completed, all users within the organization will be allowed to use the application.


Calendar Authorization App permission


Calendar Authorization App uses delegated permissions.

According to https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent 


Delegated permissions are used by apps that have a signed-in user present. For these apps, either the user or an administrator consents to the permissions that the app requests, and the app is delegated permission to act as the signed-in user when making calls to the target resource. Some delegated permissions can be consented to by non-administrative users, but some higher-privileged permissions require administrator consent. To learn which administrator roles can consent to delegated permissions, see Administrator role permissions in Azure AD. 


For delegated permissions, the effective permissions of your app will be the least privileged intersection of the delegated permissions the app has been granted (via consent) and the privileges of the currently signed-in user. Your app can never have more privileges than the signed-in user. Within organizations, the privileges of the signed-in user may be determined by policy or by membership in one or more administrator roles. To learn which administrator roles can consent to delegated permissions, see Administrator role permissions in Azure AD.


For example, assume your app has been granted the User.ReadWrite.All delegated permission. This permission nominally grants your app permission to read and update the profile of every user in an organization. If the signed-in user is a global administrator, your app will be able to update the profile of every user in the organization. However, if the signed-in user isn't in an administrator role, your app will be able to update only the profile of the signed-in user. It will not be able to update the profiles of other users in the organization because the user that it has permission to act on behalf of does not have those privileges.