Improve Power Platform authentication

[appieschot]

Description:
We currently support several Power Platform commands (flow list pa list etc). Those commands all use the following URL structure ${this.resource}providers/Microsoft.PowerApps/apps/${encodeURIComponent(args.options.name)}?api-version=2016-11-01 we have seen over the last few months that this endpoint is becoming deprecated, not returning all values that we want or is providing obstacles when retrieving data (not everything is exportable).

A list of all current open issues that are related:

• The received access token has been obtained from wrong audience or resource for the command - m365 flow export #2573
• Bug report: m365 flow export - permissions error & unhandledpromise rejection errors #2582
• Enhancement: include flows from solutions in 'flow list' #2585
• Enhancement: Add support for connecting to non-public clouds #1931
• Enhancement: extend 'flow run get' with approver information #1828

A list of all closed issues that are related:

• [QUESTION] Difference between m365 flow run get and Run history CSV export in Power Automate #1827
• Enhancements: m365 pa app list #2872
• Bug report: M365 cmdlets does not work for GCC? #2795
• M365 flow run list returns not all runs #2458

As it turns out the new PowerShell command lets have logic that could solve a lot of those issues:

• A implementation to support multiple different gov clouds for both flow, powerapps, bap & cds
• A implementation to register a custom Azure Application ID to run these calls

I suggest the following:

1. Extend our cli consent with a --service powerplatform. The implementation could use the default Power Platform App Registration (so you would need to sign in with those; that would be documentation). With the cli consent we can then consent the permissions to the default CLI App Id (or any other App ID that is part of the config)
2. Introduce a new abstraction for PowerPlatformCommand where we can implement the different gov clouds as they will have different URL's
3. Slowly refactor existing commands (or introduce new ones) based of that PowerPlatformCommands

@pnp/cli-for-microsoft-365-maintainers how do you feel about this? If we agree I would like to create a new issue for the cli consent implementation first. Feels like we can tackle a whole lot of issues and questions with that 🚀.

[garrytrinder]

Great work @appieschot 👏

There is clearly interest in these commands, as you've highlighted, and I think there are many more that we can include in the CLI, so it makes sense to tackle the emerging technical debt before adding more.

I am in favour of moving this forward 👍

[waldekmastykarz]

Great suggest and I'm all for it. Few considerations before we continue:

Extend our cli consent with a --service powerplatform. The implementation could use the default Power Platform App Registration (so you would need to sign in with those; that would be documentation). With the cli consent we can then consent the permissions to the default CLI App Id (or any other App ID that is part of the config)

cli consent is meant to consent permissions for CLI. I'd suggest that we keep it separate from the logic to register CLI as an admin app for Power Platform. Instead, I'd prefer us to implement a command like m365 pp adminapp add to register an AAD app as an admin app with Power Platform. That way, we keep it in the Power Platform command namespace and clearly indicate its purpose. At the same time, we keep the opportunity to add other CRUD commands for managing admin app registration, assuming the API will support it.

Introduce a new abstraction for PowerPlatformCommand where we can implement the different gov clouds as they will have different URL's

I'd see this implemented in a base location where it can be used by all Power Platform-related commands. We need to investigate what's the impact of it: does it influence retrieving tokens, issuing requests, options and shape of data returned by commands? We should strive to be as clear and predictable as possible to avoid confusing users.

Slowly refactor existing commands (or introduce new ones) based of that PowerPlatformCommands

Shall we refactor commands or rather leave whatever we have and deprecate it over time and over time switch to equivalent commands? The hardest part is the lack of clarity about how long the current commands will work. If we expect the current commands to stop working altogether, then it could be a good justification to refactor them. But if they keep working for the foreseeable future, then having a new set of commands in parallel and deprecation of what we have would be more favorable.

[appieschot]

Agree; will spec out a m365 pp adminapp add first, build that and then move on to spec the PowerPlatformCommand that way we can keep making progress 🚀