cli-microsoft365 icon indicating copy to clipboard operation
cli-microsoft365 copied to clipboard

New command: `cli app add`

Open milanholemans opened this issue 10 months ago • 7 comments

Usage

m365 cli app add [options]

Description

Create a new app registration to use for the CLI for Microsoft 365

Options

Option Description
-n, --name [name] Name of the app registration. Defaults to CLI for M365
-s, --scopes [scopes] Which scopes should be added? Valid values are: minimal, all. Defaults to minimal.
--saveToConfig Save the app registration info to the CLI config. This way the new app registration will be used as the default app registration to sign in.

Examples

Create a new app registration to use for CLI for Microsoft 365

m365 cli app add

Create a new app registration with all permission scopes and a custom name

m365 cli app add --name "Contoso CLI app" --scopes all

Default properties

No response

Additional Info

No response

milanholemans avatar Mar 15 '25 21:03 milanholemans

For scopes, shall we also consider folks providing their own list of scopes? This would make sense in the context of the effort to document minimal permissions for all our commands. We'd then accept as allowed values:

  • minimal
  • all
  • list of scopes, other than minimal and all

When specifying scopes, they'd need to be fully qualified (eg. https://graph.microsoft.com/User.Read instead of User.Read) so that we know to which resource they belong.

waldekmastykarz avatar Mar 17 '25 09:03 waldekmastykarz

One more thing: what about the auth type: do we assume delegated auth or do we give folks a choice between delegated and application?

waldekmastykarz avatar Mar 17 '25 09:03 waldekmastykarz

For scopes, shall we also consider folks providing their own list of scopes? This would make sense in the context of the effort to document minimal permissions for all our commands. We'd then accept as allowed values:

* `minimal`

* `all`

* list of scopes, other than `minimal` and `all`

When specifying scopes, they'd need to be fully qualified (eg. https://graph.microsoft.com/User.Read instead of User.Read) so that we know to which resource they belong.

Great idea!

milanholemans avatar Mar 17 '25 22:03 milanholemans

One more thing: what about the auth type: do we assume delegated auth or do we give folks a choice between delegated and application?

Yes, this was also something I was thinking about. However, currently, we only have a list of delegated scopes in our config.ts file. Adding an equivalent of this for application permissions would be cool tho.

milanholemans avatar Mar 17 '25 22:03 milanholemans

Yes, this was also something I was thinking about. However, currently, we only have a list of delegated scopes in our config.ts file. Adding an equivalent of this for application permissions would be cool tho.

Good point. Let's take offering the choice between delegated and application permissions as a future improvement.

waldekmastykarz avatar Mar 18 '25 08:03 waldekmastykarz

@milanholemans Can I take it?

MartinM85 avatar May 29 '25 09:05 MartinM85

Definitely, thanks!

milanholemans avatar May 29 '25 09:05 milanholemans

For scopes, shall we also consider folks providing their own list of scopes? This would make sense in the context of the effort to document minimal permissions for all our commands. We'd then accept as allowed values:

* `minimal`

* `all`

* list of scopes, other than `minimal` and `all`

When specifying scopes, they'd need to be fully qualified (eg. https://graph.microsoft.com/User.Read instead of User.Read) so that we know to which resource they belong.

Great idea!

@milanholemans I saw this idea was kinda approved but I didn't see why we did not update the spec (initial post) of this command? The currently opened PR does not allow to specify the list of scopes. Was this overlooked?

Adam-it avatar Jul 19 '25 20:07 Adam-it

Sorry @Adam-it, it's an oversight of mine

milanholemans avatar Jul 20 '25 13:07 milanholemans