M365 app commands

[waldekmastykarz]

Hey folks, we're thinking about adding a series of enhancements/commands that would help developers work with M365 apps.

The first one is extending the aad app add command with the ability to save the information about the created app registration in a local file #2815. No matter how you create your app and what kind of app you build, when you want to connect it to M365, you need an AAD app registration. You can easily create one using CLI for M365. If you build a larger solution, you can also create multiple app registrations (eg. bot, API, web app, etc.) and keep track of all of them.

Once you have a list of AAD apps linked to your solution through the .m365rc.json file, what if you could easily manage them without having to look them up in the AAD portal.

If you need to add a delegated permission, you'd call:

m365 app oauth2grant add --resource 'Microsoft Graph' --scope 'Mail.Read'

If you need to add an app-only permission, you'd call:

m365 app approleassignment add --resource 'Microsoft Graph' --scope 'Mail.Read'

To quickly navigate to the AAD app in the Azure Portal, you'd call:

m365 app aad open

And we'd give you the deeplink to the app page, or maybe even open it for you in your default browser.

If you need to get information about the app (redirect URIs, permissions, etc.), you'd call:

m365 app get

In all these commands, you don't need to specify the appId because CLI for M365 can get it from the .m365rc.json file. If you have multiple apps, you'd be prompted to choose which one you want to work with.

What do you think about this? Would it help you? Would it be enough to have just one get-command that returns the whole manifest or would you rather have more specialized commands that return pieces of it, like redirectUri list, oauth2grant list, approleassignment list, etc.? Which other commands could we introduce to help you work with M365 apps?

[stephanbisser]

I'd love to see that in the CLI for 2 reasons:

• For folks who are not that deep into auth and AAD but who are using the CLI in projects this could be a great addition to ease the process of working with AAD apps and using them in whatever solution they are building
• For projects like yo teams, this would be a perfect fit to streamline the process of developing apps which are tightly connected to AAD with auth and stuff, like for instance building a Teams tab with SSO support. I could think of a scenario where we use the CLI during the project creation experience to configure everything you need in AAD automatically so that by the end of scaffolding a project, you as the dev do not need to jump into the Azure portal because it has already been done for you, so you just consume the AAD app reg

[appieschot]

Sounds like a great idea 💡. One thing that is a bit unclear to me is how you would track multiple apps in your .m365rc.json and (I get how to store multiple items in an array but not sure how the commands would now what app you are referring to in case of getting details).

[waldekmastykarz]

When running app commands, we'd check if you have one or more apps in .m365rc.json. If you have one, that's the app we'd work with. If you have multiple, we'd prompt you to disambiguate. This could be interactive or simply a prompt - whichever we feel like is more suitable.

[plamber]

I like the idea too. The question I am not able to answer is if you want to limit the scope to specific use cases and make it as simple as possible for users without deep knowledge of apps or if you want to provide a swiss-army-knife. If the last option is desired you might have to consider creating more granular commands for all possible settings

[waldekmastykarz]

I think it will be a combination of both: we might want to simplify common use cases, but there will always be scenarios that we didn't envision and having a fallback of a generic get could be a way out. Good point 👍

[arjunumenon]

Idea is brilliant 🔥.
Because, most of the times we need to switch context to know the AppId which is needed for registration. With the concept of local file in the project directory, we can easily write scripts which will do the needed action rather than explicitly specifying the Appid which is super useful.
I can even think of bundling these commands with gulp tasks if needed.

m365 app get
In all these commands, you don't need to specify the appId because CLI for M365 can get it from the .m365rc.json file. If you have multiple apps, you'd be prompted to choose which one you want to work with.

In this case, I am assuming if we have multiple Apps in the .m365rc.json file, it will prompt us back with the Id? Can we have the possibility of keeping the name as well in the .m365rc.json file so that it will be easier for the users as well.

Would it be enough to have just one get-command that returns the whole manifest or would you rather have more specialized commands that return pieces of it, like redirectUri list, oauth2grant list, approleassignment list, etc.? Which other commands could we introduce to help you work with M365 apps?

My opinion is to start with the single command with all the manifest details. Not sure whether we can use JMES query to get the specific details if needed from the output of the single command. Maybe not. Just wondering 🤔

[waldekmastykarz]

In this case, I am assuming if we have multiple Apps in the .m365rc.json file, it will prompt us back with the Id? Can we have the possibility of keeping the name as well in the .m365rc.json file so that it will be easier for the users as well.

Yes! That's the idea, so that we work with the appId internally, but we also have the name along with it, so that users can quickly see which app is which.

My opinion is to start with the single command with all the manifest details. Not sure whether we can use JMES query to get the specific details if needed from the output of the single command. Maybe not. Just wondering 🤔

You could absolutely use JMESPath to query the app manifest for specific properties. Alternatively, you could use jq and in PowerShell you could parse the manifest to JSON and work with it as with any other object.

[Adam-it]

wow this seems like a lot of work (actually had to read it twice to fully understand this 😉... not actually sure if I still fully got it 😅).
I think it is a great idea. I like the idea of the .m365rc.json file 👍.
It seems it could also be a great starting point for maybe more functionalities that could be included there and become CLI like a project companion tool (like now the CLI actions to deploy spfx to tenant (must have in project pipeline)).

[waldekmastykarz]

Exactly @Adam-it! You got it in one go. The big question is how can we help developers build apps connected to M365 and what are the different things we could simplify. Managing AAD app registrations is one aspect. Let's think what else is there, like you mentioned 👍

[Adam-it]

this.... Is... AWESOME

[waldekmastykarz]

Thinking of possible app commands... one thing I regularly need to change myself are API permissions. It would help me a lot to have an ability to:

1. quickly see which permissions I've got granted
2. grant additional permissions
3. remove permissions

In all cases, I don't really care about the distinction between application and delegated permissions, and wouldn't mind them being throw on one pile where I can see and manage them with one command, similarly to how they're displayed in the Azure portal. What do you think folks, would this help you too?

[Adam-it]

yes I think this a really good scenario as well 👍, I also cannot think of anything more except a private scenario I may use this .m365rc.json file to store config for an small extension I written for me some time ego which uses m365 cli command 😋. For example it would be perfect case for me to store .sppkg file name (now I keep it in settings same per project so I need to change it every time per project 🤔). Now I would just take it from the json file and run m365 cli: build & deploy in vs code

[waldekmastykarz]

We could totally extend the config file with package(s) path(s)!