Would it make sense to provide M365CliCredentials as AzureCliCredential doesn't work anymore with SPO

[jhholm]

Hi,

My current development workflow with Node Azure Functions that call SPO, uses Managed Identity when running in production, and AzureCliCredential from @azure/identity while developing/debugging. It seems that some change lately has dropped support to call SharePoint APIs with Azure CLI token. Graph APIs still seem to work.

See https://stackoverflow.com/questions/76629048/accessing-sharepoint-via-visual-studio-app-is-not-allowed-to-call-spo-with-user

Using application permissions with a self signed certificate for just development purposes is a bit cumbersome in my opinion. I would like to continue working in a similar fashion as with AzureCliCredential - device code flow - delegated permissions - while debugging/developing.

So I wanted to test if I could use M365 CLI and I created a similar wrapper as AzureCliCredential that uses m365 util accesstoken get behind the scenes. This functionality seems to work as usually the PnP Management Shell service principal is configured properly for delegated permissions. I also noticed that I could use m365 cli to login with a custom service principal with device code flow.

I still need to iron out some of the quirks, but currently my initial implementation seems to work with both getting a SharePoint and Graph token with a custom service principal or the standard pnp management service principal.

I was just wondering would it make sense to add this functionality to this project, or probably somewhere else. E.g. PnPjs as they already have some wrapper functionality regarding this.

Current status/things to do:

• Works with both Graph and SPO token
• Need to add some logging and error handling
• I currently need to decode the JWT token to get the expiry date for the token
• Are there any breaking changes planned for accesstoken get?
  • e.g. Azure CLI is providing expiry date and other information as plain text when getting access token
• Is this something that would be useful?
• If so, should this be included here or with PnPjs or just as a standalone package?

[milanholemans]

Hi @jhholm, if I understand it correctly, you are having trouble using CLI in Azure Functions, using managed identity right?
If I recall it correctly, you should be able to use a system-assigned identity by running m365 login --authType identity, or user-assigned identity m365 login --authType identity --userName ac9fbed5-804c-4362-a369-21a4ec51109e.

Correct me if I misunderstood the original issue.

[martinlingstuyl]

I think he's running a node.js application with pnpjs, am I correct @jhholm?

Could you maybe explain the architecture a bit more?

If I understand correctly you're trying to find a way to setup auth in a Dev/Production scenario so that you can use managed identity on the Function while using another route in debug mode.

You're talking about wanting to use delegated mode there. But if it were me I'd use app only permissions (with a certificate) that way Dev and production both use the same setup. This may be wise among other things because some api endpoints tend to function differently in delegated mode. You'd want to be consistent, hence I'd use app only.

[jhholm]

Ah. Sorry. I was a bit ambigious. I'm actually asking if it would make sense to contribute my solution to this project. Thus I created this as an idea discussion.

I tried telling what was my issue and why I created my own wrapper. In my opinion using delegated auth while debugging and managed identity while in production is much much more user friendly approach than working around with self signed certificates.

I only mentioned PnPJs as they already have additional functionality wrapped around @azure/identity.

TLDR;

1. I was using AzureCliCredential class while developing Azure Functions to call SPO APIs for the last few years
2. Azure CLI tokens stopped working in the last few months with SPO APIs (throws an error about not allowing SPO user_impersonation)
3. I checked how AzureCliCredential code worked and wrote (or blatantly copied) a similar wrapper that I can use with m365 cli
4. I guess it could be called M365CliCredential, and I'm asking is there a place to contribute it here or might pnpjs project be a better place?

Additionally as the solution relies on calling m365 util accesstoken get, any major changes in that command would break the wrapper.