Bug report: v7.9 error message - Error: This command does not support application-only permissions.

bubbletroubles commented 3 weeks ago

Priority

(Medium) I'm annoyed but I'll live

Description

When I use m365cli version 7.9 I get the error message "Error: This command does not support application-only permissions."

Steps to reproduce

Use m365cli v7.9

Login using a secret m365 login --authType secret
run the command m365 pp managementapp list
The error message "Error: This command does not support application-only permissions." appears.

Use m365cli v7.8.1

Repeat the steps above
The command m365 pp managementapp list completes successfully

Expected results

I would expect the command that works in 7.8.1 also works in 7.9, using the same application registration/secret.

Actual results

When using v7.9, I get the error message "Error: This command does not support application-only permissions."

Diagnostics

No response

CLI for Microsoft 365 version

7.9

nodejs version

20.12.2

Operating system (environment)

Linux

Shell

PowerShell

cli doctor

Output from v7.8.1 which works

{
  "os": {
    "platform": "linux",
    "version": "#73~20.04.1-Ubuntu SMP Mon May 6 09:43:44 UTC 2024",
    "release": "5.15.0-1064-azure"
  },
  "cliVersion": "7.8.1",
  "nodeVersion": "v20.12.2",
  "cliAadAppId": "removed",
  "cliAadAppTenant": "single",
  "authMode": "Secret",
  "cliEnvironment": "",
  "cliConfig": {},
  "roles": [],
  "scopes": {}
}

Output from v7.9 which returns the error message

{
  "os": {
    "platform": "linux",
    "version": "#73~20.04.1-Ubuntu SMP Mon May 6 09:43:44 UTC 2024",
    "release": "5.15.0-1064-azure"
  },
  "cliVersion": "7.9.0",
  "nodeVersion": "v20.12.2",
  "cliAadAppId": "removed",
  "cliAadAppTenant": "single",
  "authMode": "Secret",
  "cliEnvironment": "",
  "cliConfig": {},
  "roles": [],
  "scopes": {}
}

Additional Info

Its probably related to #4054 and #5862

milanholemans commented 3 weeks ago

Hi, @bubbletroubles thank you for flagging this issue. Could you share the permission scopes with us that you configured on your app registration?

waldekmastykarz commented 3 weeks ago

To give some more details, for communicating with Power Platform API, we're using the PowerApps Service Service Principal, which doesn't support application permissions:

The only change we've applied between v7.8.1 and v7.9 is an error message that application permissions are not supported. Have you seen the command actually work with application permissions and return data?

Like @milanholemans mentioned, it would help us to know which API permissions you configured on your app reg.

bubbletroubles commented 2 weeks ago

Thanks @milanholemans and @waldekmastykarz

Here is a screenshot of the application registration

Also the commands definitely do work and output valid results on v7.8.1, while on version 7.9 they return the error "Error: This command does not support application-only permissions"

waldekmastykarz commented 2 weeks ago

All these permissions are delegated, so if you log in using a secret, your app shouldn't have any permissions and should fail when calling the API. I think that's what you showed in your original issue, where the list of roles and scopes on the token is empty. Power Apps Service doesn't support application permissions, so you can't connect to it using a flow meant for application only access, such as secret. While we can investigate why calling the command with app-only access worked in the previous version of CLI, I suggest that you consider changing the way you log in to use a delegated flow.

bubbletroubles commented 2 weeks ago

Thanks @waldekmastykarz - sorry if this is a silly question, but in my screenshot of the application registration permissions, the "Type" is delegated. Is that what you are referring to using a delegated flow, or is there a different configuration required?

milanholemans commented 2 weeks ago

That's indeed the case. If the type is delegated, that means that you need a user account to sign in. In that case you get the same permissions that user has. When using application permissions, you don't need a user to sign in and you'll have full access to the entire scope.

waldekmastykarz commented 2 weeks ago

Thanks @waldekmastykarz - sorry if this is a silly question, but in my screenshot of the application registration permissions, the "Type" is delegated. Is that what you are referring to using a delegated flow, or is there a different configuration required?

Not a silly question and sorry for taking a shortcut. When it comes to permissions, you've got delegated and application permissions. Delegated allow you to perform operations on behalf of a user. Also, if you for example grant a delegated permissions to access sites, the app can only access sites that the user who signed in to the app has access to. In comparison, application permissions don't require a user. When you grant an app an application permission, that app gets access to all resources of the specific type, like all sites, all teams, etc.

Then we get to auth flows, which allow you to authenticate your application either as a user or app-only. An example of user/delegated flows are device code or username/password. Often, delegated flows are interactive. For application flows, which are non-interactive, you've got more choice with some examples like secret, certificate or managed identity. Application/non-interactive flows are typically what you'd use in CI/CD and other automation scenarios because there's no user context involved.

I hope this clarifies it a bit.

pnp / cli-microsoft365