I am working on creating a server daemon process for automated ingesting of files from SharePoint to a private server. This is a headless (no user) app that runs via a "cron" job. So my reading of the OATH protocol indicates to me that we cannot use the /authorize or /adminconsent endpoints, since they ask for a redirect_uri (and there is no human to reply here). Correct me if I am wrong.
In OneDrive we created a group site, and also a tenant (clientID and secretID) for it and gave the daemon (not delegate, since there is no user) but application level permissions for Microsoft Graph and File.Read.All
This is all working fine, we authorize and get the bearer token by doing the 2-legged OAUTH (known in MSFT as OAuth 2.0 client credentials flow) by calling the tenant/token endpoint in the graph server site. No problem getting files either.
Except that the daemon can now read any SharePoint or OneDrive folder in our system. Not really good security practice.
Is there a way of setting up the access token so that it is restricted to only the SharePoint Document folder of the SharePoint Team that we have?
I have seen a SO question which asks a similar request: Graph API - Automate Getting Emails (Delegated Permissions)
But I do see lots of warnings in trying to use the proposed solution: ROPC = OAuth 2.0 Resource Owner Password Credentials
https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc
So is there some preferred way to restrict the bot/agent (i.e. ACLs?)
If we have to use ROPC, and create a dummy user, what access do we give that user in AD? And what do we need for the Graph API (tenantID, username, password, and client-secret?).