AddIn permissions authentication using ClientId & ClientSecret getting 401 unauthorized

[kchiragowni]

Hello,
First of all very handy wrapper to encapsulate authentication/authorization.

I am trying to authenticate to SharePoint Online using AddIn permissions using - ClientId & ClientSecret to access pages for UI testing using Puppeteer but getting 401 Unauthorized error.

Any advice would be much appreciated.

On a side note: Is it possible to use this wrapper with MFA enabled for SharePoint online?

[s-KaiNet]

Hi,

I suggest you to test your permissions using sp-request library. Try to get web details to check it works:

spr.get('http://sharepoint/sites/dev/_api/web/')
  .then(response => {
    console.log(response.body);
  })

Add-in authentication works no matter if MFA enabled or not. If you want to use user credentials authentication with MFA, then simply generate a new app password ("To create another app password" section) for you account and use it instead of real password. I.e. your credentials will be

{
 username: "your user",
 password: "app password"
}

[kchiragowni]

Thanks @s-KaiNet, actually app authentication is working fine, I could see the token generated using node-sp-auth, but I'm not able to load Sitepages in the browser using the addin permissions included in the headers.

When I add the addin bearer token to the page headers and load the page I'm getting 401 unauthoirsed.

I will explore app password to use User credentials where MFA is enabled, thanks again!

[s-KaiNet]

You can't simply include Bearer token and load the page, because Bearer authentication works for SharePoint API, not for the browser.

You should try using user creds (with app password) and attach a cookie received from the node-sp-auth to your Puppeteer instance.

[s-KaiNet]

BTW check out this - sp-auth-puppeteer-sample

[pholpar]

We had the same issue when using app-only, ClientID / ClientSecret based authentication in a tenant, that was recently created. We recieved a HTTP 401 / Unauthorized from server in the response body: '{"error":"invalid_request","error_description":"Token type is not allowed."}'. In our old tenant (created in 2013) we could use the same authentication method without any problem. As it turned out, new tenants have a standard setting in DisableCustomAppAuthentication property, that disable this kind of auth., however it can be overriden using this command:
Set-SPOTenant -DisableCustomAppAuthentication $false
Source:
https://sharepoint.stackexchange.com/questions/284402/sharepoint-online-authorization-issue-token-type-is-not-allowed
https://sharepoint.stackexchange.com/questions/286693/getting-invalid-request-token-type-is-not-allowed-error-while-accessing-lists

See the official reason:
https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azureacs
Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), has been retired on November 7, 2018. This retirement does not impact the SharePoint Add-in model, which uses the https://accounts.accesscontrol.windows.net hostname (which is not impacted by this retirement). For more information, see Impact of Azure Access Control retirement for SharePoint Add-ins. For new tenants, apps using an ACS app-only access token is disabled by default. We recommend using the Azure AD app-only model which is modern and more secure. But you can change the behavior by running ‘set-spotenant -DisableCustomAppAuthentication $false' (needs the latest SharePoint admin PowerShell).

More details:
https://www.koskila.net/literally-breaking-changes-to-app-authentication-on-sharepoint-%F0%9F%98%B5/