How can OAuth 2.0 authentication be implemented when connecting Business Central with an external API?

When Business Central needs to communicate securely with an external API, OAuth 2.0 provides a standard mechanism for obtaining and presenting access tokens rather than embedding usernames and passwords into integration code. Microsoft documents OAuth as an authentication option for Business Central web services and also documents service-to-service authentication for integrations that run without user interaction.

A typical architecture is:

Business Central
      |
      | HTTPS
      v
External API
      |
      | Authentication requirement
      v
Microsoft Entra ID / Identity Provider
      |
      v
Access Token
      |
      v
API Request
Authorization: Bearer <token>

For a service-to-service integration, the architecture should be designed around an application identity rather than an interactive user. The exact OAuth flow depends on the external API's identity provider and supported grant type.

The important implementation areas include:

Authentication configuration

Define:

• Application registration.
• Required API permissions.
• Appropriate application identity.
• Token acquisition mechanism.
• Token lifetime/refresh strategy where applicable.
• Secure credential or certificate management.

AL HTTP communication

Business Central's HttpClient is used for outbound HTTP calls. The request normally contains an access token in the HTTP Authorization header:

Headers.Add(
    'Authorization',
    'Bearer ' + AccessToken);

The actual token acquisition should be designed according to the identity provider's supported OAuth flow rather than hard-coding a token into AL.

Security principle

Never design the integration like this:

AL Code
   |
   +-- Client Secret = "my-secret"

Secrets should not be embedded in source code or exposed in logs.

Microsoft's current Business Central security guidance specifically highlights the risk of hard-coded credentials and recommends secure secret-management patterns such as Azure Key Vault for applicable integration scenarios.

Failure handling

The integration should distinguish:

401 / 403
   → Authentication / authorisation problem

400
   → Invalid request

404
   → Resource not found

429
   → Throttling / rate limit

5xx
   → Server-side/transient failure

Timeout
   → Network or service responsiveness issue

These should not all be handled with the same retry strategy.

For students: understand OAuth concepts, access tokens, bearer authentication and the role of Microsoft Entra ID.
For professionals: focus on service-to-service identity, least privilege, secret/certificate management, token lifecycle, API scopes, timeout/retry behaviour, observability and preventing credentials from entering AL source code or telemetry.