Use microsoft application credentials for authorization

[swissbyte]

Hello

I would like to be able to use the synchronisation of a sharepoint folder as automated as possible.
Therefore i would like to be able to use application credentials instead of a user that have to login.

Is this auth method already implemented?

Thanks
Regards

[abraunegg]

@swissbyte
Sorry but that sort of method to login is not implemented.

[swissbyte]

Thank very much for your quick response.
Since you know the codebase atm. better then me, do you think its hard to implement this feature?
My fears that i have with the actual code / way of operation is, that the authentication gets invalid at some point and one have to reauthenticate.

We would like to make certain folders from sharepoint available within a headless server environment and therefore it feels strange to authenticate the server application using a "personal" e-mail...

Thanks for your answer and this masterpiece of code :)

[abraunegg]

@swissbyte

Since you know the codebase atm. better then me, do you think its hard to implement this feature?

It is all about time & effort.

To support this sort of access, the user of the application would have to:

• Register a new application in Azure Active Directory. Post registration, note down the 'application id' and 'tenant id' as this will be needed
• Configure application API permissions for this application. At a minimum, the following permissions are needed:
  • Sites.Read.All
  • Sites.ReadWrite.All
  • Files.Read.All
  • Files.ReadWrite.All
• Grant Admin Consent for those permissions
• Create a Client Secret
  • In Azure Active Directory under the Application you have created, create a new client secret and provide a valid description and expiration period.
  • Copy this client secret value and store securely - as this is what the client will use for authentication

With this done, you can then configure the 'onedrive' client with the following:

• application_id - the application id created earlier.
  • Please read: https://github.com/abraunegg/onedrive/blob/onedrive-v2.5.0-release-candidate-2/docs/application-config-options.md#application_id
• azure_tenant_id - the tenant id obtained earlier
  • Please read: https://github.com/abraunegg/onedrive/blob/onedrive-v2.5.0-release-candidate-2/docs/application-config-options.md#azure_tenant_id

Now this is where the 'onedrive' gap (development effort) is needed:

• Create a new flag in the application configuration to tell the application to use a 'Client Secret'
• Have the user store this secret in an applicable file
• Read this file
• Have 'onedrive' change how the access token is being requested when using a 'Client Secret'

We would like to make certain folders from sharepoint available within a headless server environment and therefore it feels strange to authenticate the server application using a "personal" e-mail...

It is all about Identity and Access Management. You want 'traceability' on who did what and when for auditability when things go wrong. Using a 'Client Secret' means you do not get this - as once this 'shared key' is known, anyone can access the data using this shared key and 'hide' what they are accessing and doing - it is generally not a good idea security posture wise:

Security Risks:

• Shared Credentials: Since the client secret is a shared credential, if it gets exposed or compromised, anyone with access to it can act as the application, potentially accessing or modifying sensitive data.
• Hard to Rotate: Regularly rotating client secrets can be cumbersome, and failure to do so increases the risk of prolonged exposure if the secret is compromised.
• No Granular Control: There's no way to enforce granular access control policies for different parts of your application when using a single client secret.

Lack of Accountability and Auditability:

• No User-Specific Logging: Actions performed using the client secret are logged under the application’s identity, not individual users. This makes it difficult to track who performed specific actions, hindering auditability and accountability.
• Difficult to Revoke Access: If access needs to be revoked for a specific user or service, it’s not possible without rotating the client secret and updating all places where it is used, potentially causing service disruptions.

Compliance Issues:

• Regulatory Non-Compliance: Many regulatory standards (such as GDPR, HIPAA) require strict access controls and audit trails. Using client secrets can make it difficult to meet these requirements.
• Lack of MFA: Client secret authentication doesn’t support multi-factor authentication (MFA), which is a common requirement for secure access to sensitive data.

So in saying this, implementing application credentials via a client secret is not really a good idea, so I am most likely never going to implement that capability to ensure this client can comply when used within regulated environments.

This being said, the most viable alternative to 'Client Secret' is to use ' Azure Managed Identity' with potentially specifying a 'client id' (which might be the 'application id') to access the the appropriate resources.

All of this would be quite a heavy development effort to support 'Azure Managed Identity' and this is not something which is on any feature request or whiteboard item to look at, thus will not be probably be looked at in the short or medium term.

... using a "personal" e-mail...

When you authenticate to SharePoint online, it is using your account credentials already - which will include the email associated with your account. Again this all comes back to Identity and Access Management. You do not need to access your SharePoint site with a 'personal (non-corporate)' email account. You access the SharePoint site using your normal 'business' credentials.