DarrelMiller Certainly most of these things can be achieved with delegate permissions but that doesn’t mean they should.
For example, in the UC use case we operate a UC platform that provides open APIs for any application with permissions to be able to get or set the presence of a user. I could fairly easily write a service that consumes presence from the Microsoft Graph and publishes this into our other UC platform. At the moment, as delegate permissions are the only option I have to write an additional application that runs somewhere, in the context of someone, to collect this information using delegate permissions. I’d probably end up just creating a user account for a service to run as, and then having to authenticate that service account periodically to get a token to use with Graph. Writing a service with application permissions is more robust, more scalable, and doesn’t rely on a temporary authorisation.
I think the most important takeaway here from my perspective is that we don’t always have the option to just build in support for delegate permissions — I’m sure mine isn’t the only business working with legacy applications that provide integration APIs, but which don’t allow us to just bolt on the necessary UI and boilerplate code to use delegate permissions. With application permissions I can write headless services that perform the integration work through APIs with no dependencies on users. Without application permissions my applications have to take a UI dependency on Graph which just isn’t feasible in many older applications or deployments.
I’m happy to elaborate further on any of these points.