Allow Connect-Graph authentication via x509 certificate provided in-memory vs. having to be in local machine store on disk

[ryanspletzer]

We have a lot of scenarios where we want to run automations against the Microsoft Graph from Azure Automation, and, unless we curated our own hybrid workers on our own VM's where we have full control over the local cert store, it's often not feasible in this type of scenario to import a cert for authentication into the local cert store. (We still need to test to see if this is possible in a cloud ephemeral worker in Azure Automation -- even if it is, leaving a cert around in seems sort of dicey, hopefully workers are cleared between runs, but you never know...)

In any case, it would be great to be able to pass a certificate to Connect-Graph in-memory to facilitate scenarios where you can't reasonably import a cert from the local cert store for authentication. (Or, another alternative would be to allow the use of client_id + client_secret, but there may have been good reasons why client_secret support wasn't implemented; certs may be preferred.)
AB#6431

[KirkMunro]

Yes! This would be of huge value to the project I'm working on. CBA is wonderful, but being able to use it in transient compute environments (Azure functions, containers) without having to have the certificate loaded in the certificate store would be wonderful! Of course, since I also need the MicrosoftTeams module to do things that the Graph module bundle does not allow me to do yet, that value may not be realizable for me until it was supported for MicrosoftTeams as well, but I still stand behind this being an important feature to add.

[jannickoeben]

I second this feature. This makes it possible to store the certs in Azure Keyvault.

[ryanspletzer]

It turns out (and this is not documented!) that Azure Automation actually does put certificates into the local currentuser store for the workers that run the runbooks. But the issue still stands that there are execution environments where this is not feasible.