Sp-dev-docs: This type of User/Pwd authentication recommended on this page no longer seems to work for SPO

[tafs7]

As of last week, it seems that SharePoint Online and AAD no longer like the user/pwd model of authentication. In fact, switching to Client Secrets doesn't even work for SPO any more. While you're able to obtain an access token given an appId & client secret, SPO always returns a 401 when you try to create a ClientContext with that access token as bearer token on the request.

HOWEVER, if you change the code to use a certificate, upload a cert to AAD admin center and then use that cert in the code base to authenticate using Microsoft.Identity.Client.IConfidentialClientApplication.AcquireTokenForClient(...), that token now seems to be make SPO happy and it is able to provide a successful ClientContext request.

Not sure why that is the case now, but worth doing some due dilligence and then updating this page article to reflect or at least inform other readers of that option.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 80e62a9d-06d0-ebc3-2c99-ce459388182a
• Version Independent ID: 07d8b090-b18c-842d-ba1e-0f2b2a127ad3
• Content: Using CSOM for .NET Standard instead of CSOM for .NET Framework
• Content Source: docs/sp-add-ins/using-csom-for-dotnet-standard.md
• Product: sharepoint
• GitHub Login: @spdevdocs
• Microsoft Alias: spdevdocs

[msftbot[bot]]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[Jerry0527]

Yes, all other options are blocked by SharePoint Online except certificates:

Granting access via Azure AD App-Only

[andrewconnell]

This page needs to be updated with the recent changes... just on the backlog.

[tafs7]

Thanks for the clarification @Jerry0527 and @andrewconnell. There are lots of SO and blog writeups out there with some misleading and confusing information about how to do this. Glad you guys are looking to update the official MS Docs soon.

Would love to see details on building custom apps/libs that talk to SPO via CSOM on .NET Core, with or without PnP Framework, and recommended (only?) method of authentication, best practice recommendations for token handling and management.

Thanks!

[andrewconnell]

@tafs7 Aside from the cert guidance, not sure what more is needed. Your request is pretty open-ended... I don't foresee that doc getting created in the near future.

[tafs7]

@andrewconnell I meant for example providing guidance on the token cache. The current page implements a custom in-memory cache via a ConcurrentDictionary and a ton of lower level code dealing with Semaphores. Seems overkill, and I think readers arriving at this page could benefit from guidance and suggestions for using, for example, the .NET InMemory cache or Azure Redis Cache, etc. vs. having to manage this sample code.

Some may not even realize that the proposed sample code is not safe for distributed/scaled environments since the token cache exists in memory per server. Not to mention, there's a ton of code in that sample that does "interesting" things to circumvent the async/await pattern (e.g. calling WaitAsync().ConfigureAwait(bool)).

The article mentioned by @Jerry0527 should go hand in hand with this page, and should be mentioned by this page. However, there's no mention of it. There should be continuity in these articles otherwise it takes some diligence and lots of trial/error + googling to find the disparate articles (plus the hands full of SO threads and blog post), in order for one to put together a complete and cohesive implementation that is not just copy/pasted sample code.

Other interesting bits to include:

• guidance or links on using the MSAL ConfidentialClientApplicationBuilder
• guidance or links on using an existing HTTP Client (e.g. implementing the IMsalHttpClientFactory) as larger server apps probably will want to manage their HTTP Client using DI to prevent socket exhaustion
• guidance or links for the logging callback set up

HTH