SharePoint Connector Documentation
Index

Authentication Methods

The SharePoint Connector supports multiple authentication methods to connect Business Central with SharePoint. This page explains each method and helps you choose the right one.

Authentication Overview

Available Methods

Method Description Best For
Proxy Single shared account Simplicity, consistent access
Personal Per-user authentication Audit trails, individual permissions
Certificate Certificate-based auth Advanced security scenarios

Microsoft Login Methods

With Proxy and Personal authentication, the Microsoft Login Method decides how the user signs in to Microsoft (the OAuth flow). Certificate authentication ignores it.

Microsoft Login Method Description Best For
PKCE Browser sign-in (authorization code with PKCE), with the connector's app registration or your own, no client secret Simple setup without your own app registration, Business Central Online. Default for new setups
Device Code Sign in on a Microsoft page with a one-time code, with the connector's app registration Simple setup, on-premises without your own app registration, no pop-ups
Modern App Registration Your own app registration with a client secret, signing in through Business Central's built-in OAuth sign-in Production, one redirect URL for all environments
App Registration Your own app registration with a client secret and the connector's own callback page Existing installations, production

PKCE and Modern App Registration are the newer login methods. App Registration and Device Code remain fully supported, so existing installations keep working without changes.

Login Methods at a Glance

PKCE Device Code Modern App Registration App Registration
Your own app registration Optional (blank Client Id = connector's) No (connector's) Required Required
Client secret No No Yes Yes
Redirect URL (Callback URL) .../OAuthLanding.htm None .../OAuthLanding.htm ...?page=70319501, one per environment
Redirect platform in Microsoft Entra Mobile and desktop applications - Web Web
Sign-in Pop-up window Code entered at microsoft.com/devicelogin Business Central sign-in pop-up Pop-up window
Microsoft identity platform endpoint v2.0 v2.0 (common) v2.0 v1 (common)
Entra Tenant Id field Optional Not used Optional Not used
Business Central Online Yes Yes Yes Yes
Business Central on-premises With your own app registration Yes Yes Yes

All four request the delegated SharePoint permission AllSites.Manage and a refresh token, so a user signs in once and the connector renews the access token silently afterwards.

Proxy Authentication

How It Works

With proxy authentication:

  1. One account authenticates to SharePoint
  2. All Business Central users share this connection
  3. SharePoint actions appear as the proxy account
  4. BC permissions control what users can do

When to Use

  • Simple setups where audit per user isn't needed
  • When all users should have the same SharePoint access
  • Small teams with shared document responsibilities

Configuration

  1. Set Authentication Method to "Proxy"
  2. Configure OAuth (App Registration, Device Code, Modern App Registration or PKCE)
  3. Click Connect and authenticate
  4. The connection is shared by all users

Considerations

Aspect Proxy Behavior
Audit Trail All actions show as single account
Permissions Same SP permissions for all users
Token Management Single token to manage
User Experience No individual login needed

Personal Authentication

How It Works

With personal authentication:

  1. Each user authenticates individually
  2. Users connect with their own Microsoft 365 account
  3. SharePoint actions appear as the individual user
  4. SharePoint permissions are per-user

When to Use

  • Audit trails are required per user
  • Different users need different SharePoint access
  • Compliance requires individual authentication
  • Enterprise environments

Configuration

  1. Set Authentication Method to "Personal"
  2. Configure OAuth method
  3. Each user clicks Connect on first use
  4. Users authenticate with their own credentials

User Experience

On first access:

  1. User opens a page with SharePoint FactBox
  2. Prompted to connect if not authenticated
  3. Follows OAuth flow to authenticate
  4. Connection is established for that user

Considerations

Aspect Personal Behavior
Audit Trail Actions tracked per user
Permissions User's own SP permissions apply
Token Management Each user has own token
User Experience Initial authentication required

Certificate Authentication

How It Works

Certificate authentication uses a digital certificate instead of a client secret:

  1. The connector generates a self-signed certificate using the CreateCertificate procedure (SP.CreateCertificate())
  2. The generated certificate is used to authenticate to Microsoft Entra ID (Azure AD)
  3. No client secret storage in BC required

When to Use

  • Enhanced security requirements
  • Avoiding client secret management
  • Automated processes without user interaction

Configuration

  1. Set Authentication Method to "Certificate" on the SharePoint Setup page.
  2. Click the assist-edit (the ... button) on the Certificate field. The connector generates a self-signed certificate via SP.CreateCertificate() and downloads the public key as sharepointconnector.cer.
  3. Upload the sharepointconnector.cer file to your Microsoft Entra app registration under Certificates & secrets.
  4. Make sure the Client Id field is filled in on the SharePoint Setup page. The Client Id is still required: the certificate flow uses the OAuth client_credentials grant with the Client Id and the scope <Base URL>/.default. No client secret is required.
  5. Click Connect to acquire a token using the stored certificate.

Important: Certificate authentication is an app-only flow. The app registration must be granted a SharePoint application permission (not just the delegated permissions used by the other flows), and admin consent must be granted for it. See Microsoft Entra App Registration.

Microsoft Login Methods Explained

App Registration

Uses an Azure AD registered application:

Advantages:

  • Full control over permissions
  • Central administration
  • Production-grade security
  • Supports both proxy and personal

Setup Steps:

  1. Register an app in Microsoft Entra ID
  2. Configure required API permissions
  3. Create a client secret
  4. Enter credentials in SharePoint Setup

See Microsoft Entra App Registration for detailed steps.

Device Code

Uses browser-based authentication flow:

Advantages:

  • Simple to configure
  • No Azure AD app setup required
  • Good for testing and evaluation
  • Works out of the box

Setup Steps:

  1. Set Microsoft Login Method to "Device Code"
  2. Click Connect
  3. Follow browser prompts to authenticate
  4. Return to Business Central

Limitations:

  • Requires user interaction
  • Less control over permissions
  • May not meet enterprise requirements

Modern App Registration

Uses your own Azure AD registered application, like App Registration, but signs in through the standard Business Central OAuth module (the same sign-in window Business Central uses for its own Microsoft 365 integrations) instead of the connector's callback page:

Advantages:

  • Uses the standard Business Central redirect URL (.../OAuthLanding.htm), no page=70319501 Callback URL to maintain per environment
  • Uses the Microsoft identity platform v2.0 endpoint with the SharePoint scope <Base URL>/AllSites.Manage
  • The sign-in returns a refresh token, so users sign in once and the connector renews the access token silently, like the other login methods
  • Supports both proxy and personal

Setup Steps:

  1. Register an app in Microsoft Entra ID with a Web redirect URI set to the Callback URL shown on the SharePoint Setup page (.../OAuthLanding.htm, filled in when you select the login method)
  2. Add the delegated SharePoint permission AllSites.Manage and grant admin consent
  3. Create a client secret
  4. Set Microsoft Login Method to "Modern App Registration" and enter Client Id and Client Secret Value (on-premises without Microsoft Entra authentication also the Entra Tenant Id, the Directory (tenant) ID of the app registration)
  5. Click Connect and sign in when the Business Central sign-in window opens

How it works:

  • Connect opens the Business Central sign-in window, which always shows the account picker. The connector stops before the window opens if the Client Secret Value is missing.
  • The sign-in authority is login.microsoftonline.com (or .us for the US Government cloud) followed by the tenant: the Entra Tenant Id field when it is filled in, otherwise the Microsoft Entra tenant of the Business Central environment, otherwise common.
  • After the sign-in the connector reads the refresh token from the result and stores it. Later renewals are a normal refresh token request to the v2.0 token endpoint with the Client Id and Client Secret Value, without any window.
  • If the refresh token cannot be read from the sign-in result, the connector keeps the Business Central token cache instead and checks right away that it can renew from it. If that check fails, Connect reports the error immediately instead of leaving a connection that asks users to sign in again on every page.
  • Closing the sign-in window before finishing shows "The sign-in was not completed." and leaves the setup unchanged.

Limitations:

  • You maintain a client secret, which expires (see Security Best Practices below)
  • AADSTS65001 during Connect means the app registration has no consented delegated SharePoint permission, typically because it was made for Certificate authentication (application permissions only)

See Microsoft Entra App Registration for detailed steps.

PKCE

Signs in with a normal Microsoft sign-in window. With the Client Id field blank it uses the SharePoint Connector's own multi-tenant app registration, so no app registration or client secret is needed in your tenant. It uses the OAuth authorization code flow with PKCE (Proof Key for Code Exchange) as a public client, and the sign-in window returns to the standard Business Central page (https://businesscentral.dynamics.com/OAuthLanding.htm).

PKCE is the Microsoft Login Method of a new SharePoint Setup.

Advantages:

  • No app registration, client secret or Client Id to maintain (leave Client Id blank)
  • No client secret that can expire, also when you use your own app registration
  • Normal sign-in window instead of entering a code on a separate page
  • The sign-in returns a refresh token, so users sign in once
  • Supports both proxy and personal

Setup Steps:

  1. Set Microsoft Login Method to "PKCE" (the Callback URL is filled in with the OAuthLanding.htm page)
  2. Leave Client Id blank to use the SharePoint Connector app registration
  3. Click Connect and sign in in the Microsoft sign-in window (allow pop-ups, or click Sign in)
  4. Consent to the SharePoint permission when asked (an administrator can consent for the whole organization)

How it works:

  • Connect removes the current stored connection, opens the page Sign in to SharePoint, and opens the Microsoft sign-in window from it. The window always shows the account picker.
  • For every sign-in the connector creates a new random code verifier and state. Only a SHA-256 hash of the verifier (the code challenge) is sent with the sign-in, and the verifier itself is only sent when Business Central redeems the code. A code intercepted on its way back is useless without it, which is why no client secret is needed.
  • Microsoft returns the code to the OAuthLanding.htm page, the sign-in page in Business Central picks it up, checks the state, and redeems it at the v2.0 token endpoint with the scope <Base URL>/AllSites.Manage offline_access.
  • The refresh token is stored like with the other login methods and renewed silently, without a client secret.
  • The tenant in the sign-in address is the Entra Tenant Id field when it is filled in, otherwise common.

Using your own app registration: fill in Client Id with its Application (client) ID. No client secret is used, so the app must be set up as a public client:

  • Under Authentication, add the platform Mobile and desktop applications with the redirect URI https://businesscentral.dynamics.com/OAuthLanding.htm (on-premises: the Callback URL shown on the setup page) (not Web, which requires a client secret, and not Single-page application, which cannot be redeemed by Business Central)
  • Set Allow public client flows to Yes
  • Add the delegated SharePoint permission AllSites.Manage and grant admin consent
  • If the app registration is single tenant, fill in Entra Tenant Id with its Directory (tenant) ID

When you switch to PKCE while Client Id is filled in, a message reminds you that PKCE will use that app registration. An app registration made for App Registration or Modern App Registration (platform Web) does not work with PKCE; clear the Client Id or use a separate app registration. The connector recognizes this mistake (AADSTS7000218 or AADSTS9002327) and tells you how to fix the platform.

Limitations:

  • With the connector's app registration, Business Central Online only: its registered redirect URL is https://businesscentral.dynamics.com/OAuthLanding.htm. On-premises, use your own app registration or Device Code.
  • Your organization must allow users (or an administrator) to consent to the app, like with Device Code
  • The connector's PKCE app registration is a different app than the Device Code app registration, so consent given for one does not cover the other

Note: Switching the Microsoft Login Method invalidates stored connections. Click Connect again after switching (with Personal authentication, every user must reconnect).

Choosing the Right Configuration

Decision Matrix

Scenario Authentication Microsoft Login Method
Quick evaluation Proxy PKCE (Client Id blank) or Device Code
Small business, simple needs Proxy PKCE (Client Id blank)
Small business, production Proxy PKCE or Modern App Registration
Enterprise, shared access Proxy Modern App Registration, or PKCE with your own app registration
Enterprise, audit required Personal Modern App Registration, or PKCE with your own app registration
Compliance requirements Personal Modern App Registration, or PKCE with your own app registration
On-premises, no app registration Proxy or Personal Device Code
Browser pop-ups not allowed Proxy or Personal Device Code
Existing installation that works Unchanged Keep App Registration or Device Code, no need to switch

Use your own app registration when your organization does not allow consent to third-party (multi-tenant) apps, or wants to control the app's name, owners and conditional access policies itself.

Recommendation by Environment

Environment Recommended
Sandbox/Testing Proxy + PKCE
Small Production Proxy + PKCE
Enterprise Production Personal + Modern App Registration, or Personal + PKCE with your own app registration
On-premises Proxy or Personal + Modern App Registration (or Device Code)

Switching an Existing Installation

To move an installation from App Registration or Device Code to one of the newer login methods:

  1. Change Microsoft Login Method. The Callback URL is replaced with the OAuthLanding.htm page.
  2. For Modern App Registration: add that URL as a Web redirect URI to your existing app registration; the Client Id and Client Secret Value can stay. For PKCE: clear the Client Id, or use a separate public client app registration.
  3. Click Connect (with Personal authentication, every user must connect again).

Azure Cloud Options

The SharePoint Connector supports the following Azure cloud environments:

Azure Cloud Value
Public Standard Azure / Microsoft 365
US (Government) Azure Government Cloud

This setting is configured in the SharePoint Setup page and determines which Azure endpoints are used for authentication and API calls.

Multi-Company Considerations

Separate Access Token per Company

When enabled:

  • Each company maintains its own OAuth token
  • Users may need to authenticate per company
  • Useful when companies have different SharePoint sites

Configuration

  1. Enable "Separate Access Token per Company" in setup
  2. Configure connection in each company
  3. Users authenticate per company as needed

Authentication Troubleshooting

Common Issues

Issue Cause Solution
Connect fails Invalid credentials Verify Client ID/Secret
Token expired Session timeout Re-authenticate
Permission denied Missing consent Grant required permissions
User can't connect Personal auth required User must authenticate individually
No sign-in window opens (PKCE, Modern App Registration, App Registration) Pop-up blocked Allow pop-ups, or click Sign in on the PKCE sign-in page
PKCE: "...registered under the wrong platform..." Your own app registration uses the Web or Single-page application platform Move the redirect URI to Mobile and desktop applications and set Allow public client flows to Yes
PKCE: "state mismatch" An older sign-in window answered Close all sign-in windows and click Connect again
AADSTS50194 (Modern App Registration, PKCE) Single-tenant app registration signed in through the common endpoint Fill in Entra Tenant Id

See Authentication Tips and Tricks for more messages per login method.

Token Expiration

OAuth tokens expire periodically:

  • Access tokens: Typically 60-90 minutes
  • Refresh tokens: Typically 90 days
  • The connector handles refresh automatically
  • The access token is reused within a Business Central session until shortly before it expires, so opening pages does not contact Microsoft Entra every time
  • Long inactivity may require re-authentication

Re-Authentication

If authentication issues occur:

  1. Open SharePoint Setup
  2. Click "Disconnect"
  3. Click "Connect" to re-authenticate
  4. For personal auth, each affected user must reconnect

Security Best Practices

  1. Use your own app registration for enterprise production - Modern App Registration, or PKCE with your own public client app registration, gives you control over the app, its owners and conditional access
  2. Prefer login methods without a secret - PKCE and Device Code have no client secret that can leak or expire. With App Registration or Modern App Registration, rotate client secrets before they expire
  3. Use Personal auth for auditing - When tracking is important
  4. Review permissions - Only grant what's needed
  5. Monitor token usage - Watch for unusual access patterns