New command: `cli app add`
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
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
minimalandall
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.
One more thing: what about the auth type: do we assume delegated auth or do we give folks a choice between delegated and application?
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.Readinstead ofUser.Read) so that we know to which resource they belong.
Great idea!
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.
Yes, this was also something I was thinking about. However, currently, we only have a list of delegated scopes in our
config.tsfile. 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.
@milanholemans Can I take it?
Definitely, thanks!
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.Readinstead ofUser.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?
Sorry @Adam-it, it's an oversight of mine