An app registration portal provides really important automation that many large orgs have written to let developers create apps without overwhelming IT with hundreds of manual operations.
DelegatedPermissionGrant.ReadWrite.All application permissions can do these things (from the docs):
- Allows the app to grant or revoke any delegated permission for any API (including Microsoft Graph), without a signed-in user.
Addition of delegated permissions could enable an app to perform unexpected actions on behalf of a user without requesting consent. If the user is an admin user this could be damaging. Removal of delegated permissions could cause some unexpected consent prompts. Probably not as bad.
To mitigate risk, I have seen large, security conscious orgs create a low-permissions portal for gathering all the requirements of an app request. If the app has low permission requirements, the portal just creates the app (using App Permissions not delegated permissions). If the app has high requirements, the portal creates a ticket for someone in IT to click a link triggering a different highly-permissioned (like Global Admin) and highly protected app to provision (and log the creation of) the highly permissioned app.
App Permissions allow the app to operate on its own, not in the context of the user. This could be useful if the user doesn't have permissions to perform the required operation.
From StackOverflow: Azure AD App Application Permissions vs Delegated Permissions.
From LinkedIn: https://www.linkedin.com/pulse/azure-app-registration-delegated-vs-application-permission-daniel-kim/.
From Microsoft docs: https://learn.microsoft.com/en-us/azure/active-directory/develop/permissions-consent-overview#permission-types
Just my .02.