Cli-microsoft365: Enhancement: login with appId/appSecret to AAD/Microsoft Graph

Created on 29 Mar 2019  路  9Comments  路  Source: pnp/cli-microsoft365

Hi guys,

I was wondering if it was by design that the aad and graph login commands do not support (yet) using app Id / app secret to connect in app-only context ?

The PnP PowerShell has that capability:
See command doc

Regards,
Yannick

enhancement

Most helpful comment

Lol, that doc is so rude 馃槃

All it seems that we can close that issue and open a new one when the times get better.

All 9 comments

Nope, it's not on purpose. It's something that simply never came up. It would be a good addition to the login options in the CLI, but if we were to add it, then we should do so consistently to all login commands instead of just aad and graph.

I will pickup this now.

Here is my proposal:
o365 login --authType clientSercet --secret 'abc'

Introducing additional clientSercet authType.
Introducing additional option sercet that is mandatory when the type is clientSercet:
--secret [secret] - A secret string that the application uses to prove its identity when requesting a token.

@waldekmastykarz , I seek for your advice here.

I have it almost done in this branch, however I have a blocker. Here is the current situation:

  1. Everything works as expected, token is retrieved when using client secret and can be used with the Microsoft Graph for example.
  2. The issue is with the SharePoint APIs where I get error Unsupported app only token.

After some research I found that the way we expect to work is not the way Microsoft did it so it is a little inconvenient as usual. There is a way to make it work with the SharePoint apis, but we have to engage the old Access Control Service (ACS) way of authentication an app and I am not very confident that this is a good thing since this service could be removed any moment without any notes in advance.

Here are my suggestions on how we can possibly proceed:

  • Option 1 - Do not introduce login with client secret until Microsoft fix it. It will not be convenient for the CLI to make login with client secret available, but to leave it none working for SharePoint APIs.
  • Option 2 - Make it work using ACS for the SharePoint APIs which will require additional coding to identify if the audience is SharePoint, but also will introduce risk since that service can stop working without notification as well as it might not be as secure as the rest of the login options.

Let's not bring ACS into the game, because it would mean a lot of retrofitting for something, as you mentioned, might go away any time. Do you have some more detail regarding what's wrong with the standard approach?

Not sure what do you mean by standard approach @waldekmastykarz .

Once you are authenticated using client secret you cannot work with the SharePoint apis, this is my concern.

I don't expect this to change anytime soon, Azure AD App Only authentication has been with certificates authentication only since as long as I can remember.
Docs.microsoft.com statement on this subject: https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azuread#can-i-use-other-means-besides-certificates-for-realizing-app-only-access-for-my-azure-ad-app

Lol, that doc is so rude 馃槃

All it seems that we can close that issue and open a new one when the times get better.

I closed that issue based on the discussion above. If SPO Apis ever work without the need of ACS authentication we can create new backlog item and implement it.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

waldekmastykarz picture waldekmastykarz  路  3Comments

phillipharding picture phillipharding  路  3Comments

OodapowUiPath picture OodapowUiPath  路  3Comments

plamber picture plamber  路  3Comments

garrytrinder picture garrytrinder  路  3Comments