What we want to do is have a custom web app (React UI / .NET Core backend) at say


which is not in our SharePoint farm, but have it access data (full CRUD) in lists at


We are fine with using access tokens and registering the high-trust add-in/app and configuring the certs and all that, but the more I follow the links in these articles and figure out how to get it all working, it all seems to end at adding the app to the site contents of a SharePoint site (which also requires the configuring of a weird parallel app domain in DNS, which I don't think we want to do either).

Adding the app to a SharePoint site to me means users will have to go to the SharePoint site to access the app, which is not what we want. We want them to open a browser and go directly to


in order to use it.

So is it possible to have something that is accessed outside SharePoint behave like a high-trust add-in/app?

This is all on-prem.

  • can't you use the page viewer? if the site is in your trusted ie sites it should work, if you are trying to connect to sharepoint from the add-in, then you have to establish a cross-domain connection
    – Mike
    May 3, 2018 at 20:46

2 Answers 2


it seems to me that you want to create a .net CSOM solution.

you would need to use the PNP authentication manager to be able to talk with sharepoint from the add-in

  • I looked into the authentication manager, this does seem like it might be a viable solution. Do you happen to know if the CSOM and the PNP code will work on .NET Core 2.0? May 3, 2018 at 22:06
  • ohh no.. CSOM is 4.5
    – Mike
    May 3, 2018 at 23:13

What you're referring to is a "Provider Hosted App", not to be confused with "SharePoint Hosted App". It's a custom app running on whatever framework you choose, talking plain old web tech to SharePoint using tokens for authentication.

It involves setting up an app "Client Id" and "Secret" on your SharePoint site, which are effectively a username/pass combination for your app to authenticate to SharePoint. The app is also given access to specific resources, such as view-only on a specific list, or full access to the entire site collection.

You control access to your app in whichever way you choose. The app can either elevate permission of whoever uses it to the level the app has, or it can "pass through" the user context so if the user can't access the site, the app won't let them in either.

Research "SharePoint provider hosted applications using CSOM". It can get a bit heavy, fair warning.


To add some context, I've setup Windows Services that run autonomously and read/write data in SharePoint. This is done with the "AllowAppOnlyPolicy='true'" permission setting when setting up app credentials (client id / secret).

I've also setup custom web apps that pull data from SharePoint, merge it with data from other sources such as SQL, Exchange, etc, and then present it on a dashboard, all without every "touching" SharePoint directly (at least through the UI).

The App never needs to be "installed", unless you want custom add-in parts (webparts) that iframe parts of your custom app or something like that. It just needs "Access" which is given with clientid/secret. The OAuth flow that happens using those bits is where things get tricky.

The following urls might help clarify the app registration process:

<sp site url>/_layouts/15/appregnew.aspx (Step 1 - generate id/secret)
<sp site url>/_layouts/15/appinv.aspx (Step 2 - grant access, AllowAppOnlyPolicy, etc)
  • No, I know it's a provider hosted app, but what I'm getting at is that even if it's a provider hosted app, in order for users to use it, they have to go to a SharePoint site to then interact with my custom app, presumably through an iframe or something, correct? Users can't go directly to my app's URL of https://mycustomapp.mydomain.com which is outside of SharePoint, and use my app directly there, while it still behind the scenes accesses data in SharePoint. May 3, 2018 at 22:01
  • To achieve that you'll want to look at "AllowAppOnlyPolicy='true'" when setting up the app credential. This effectively bypasses the need to authenticate as a user against the SharePoint site, but also "elevates" the permission of users to whatever the app has. So be sure you secure your custom app appropriately to prevent security holes.
    – Chad
    May 3, 2018 at 22:04
  • See my edits, here's a decent example: blogs.msdn.microsoft.com/kaevans/2013/02/23/… ... ignore the ACS, S2S bit, focus on the pattern.
    – Chad
    May 3, 2018 at 22:50
  • Gotcha. So just to make sure I understand - if we register the app and set it up to be able to have "app only" access, we don't need to go all the way through and install it in a SP site. But from my understanding, we will still either need to set up a low trust scenario and have Azure ACS issue tokens for our custom app to use, or set up a high trust scenario and generate the tokens ourselves. Is that accurate? May 4, 2018 at 19:43
  • With on-prem I don't believe ACS is involved, the SharePoint site should be able to generate the tokens needed in either high/low trust scenario. With high trust, you would just need to have your app redirect to sharepoint to acquire the token, which then immediately redirects back with a POST that includes the token. If you're using Windows Integrated this process should be seamless. Check out Microsoft's TokenHelper utility class for specifics.
    – Chad
    May 7, 2018 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.