---
id: post/jpearson-blog/1485
type: post
title: Calling Business Central APIs Without a Client Secret
summary: "Explains how an Azure Function or Static Web App backend can call Business Central APIs without a client secret: the function gets a managed identity token, then exchanges it via a federated credential on the app registration for a token that BC accepts. The author notes this still works but a newer post describes a better way that calls BC directly from a managed identity."
tier: community
language: en
tags:
  - authentication
  - apis
  - azure integration
  - managed identities
  - oauth
  - security
  - token exchange
  - service-to-service
system: integration
review:
  state: reviewed
  by: opus
  at: "2026-10-08T02:00:27.323Z"
  flags: []
generated:
  at: "2026-10-08T01:26:53.141Z"
  pipeline: 0.2.0
  prompts:
    extract-post: 1
  input_hash: 39044525413be9f56cb06dbc94f949509590bea05a6a24538210bb3e1424754a
evidence:
  - kind: blog
    url: https://jpearson.blog/2025/07/04/calling-business-central-apis-without-a-client-secret/
    title: Calling Business Central APIs Without a Client Secret
    date: "2025-07-04"
    commit: null
    t: null
    quote: null
  - kind: blog
    url: https://jpearson.blog/2025/07/04/calling-business-central-apis-without-a-client-secret/
    title: Calling Business Central APIs Without a Client Secret
    date: "2025-07-04"
    commit: null
    t: null
    quote: We need to exchange the token we've already got for a token issued for the app registration.
  - kind: blog
    url: https://jpearson.blog/2025/07/04/calling-business-central-apis-without-a-client-secret/
    title: Calling Business Central APIs Without a Client Secret
    date: "2025-07-04"
    commit: null
    t: null
    quote: It would be better if we had a solution that didn't rely on client secrets.
links:
  learn: []
  objects: []
  features: []
  topics: []
  localizations: []
  videos: []
  posts: []
  guidelines: []
post_id: "1485"
source_id: jpearson-blog
source_name: James Pearson
url: https://jpearson.blog/2025/07/04/calling-business-central-apis-without-a-client-secret/
published_at: "2025-07-04T11:44:19.000Z"
author: James Pearson
full_text: false
words: 1252
quotes:
  - text: We need to exchange the token we've already got for a token issued for the app registration.
    why_it_matters: "This explains the core mechanism: the managed identity token alone is insufficient; it must be exchanged for an app registration token that has Business Central permissions."
  - text: It would be better if we had a solution that didn't rely on client secrets.
    why_it_matters: "States the motivation: avoiding secrets eliminates expiration management, key vault dependencies, and credential compromise risks."
code_objects_mentioned: []
systems:
  - integration
  - administration
  - platform
versions_mentioned: []
preview:
  embeddable: true
  frame_url: https://jpearson.blog/2025/07/04/calling-business-central-apis-without-a-client-secret/embed/
  image: https://jpearson.blog/wp-content/uploads/2025/07/image-2.png
  image_alt: null
  image_w: 855
  image_h: 331
  site_name: James Pearson
  favicon: https://jpearson.blog/wp-content/uploads/2018/09/cropped-semicolon.jpg?w=32
  probed_at: "2026-10-07T11:51:03.633Z"
---

# Calling Business Central APIs Without a Client Secret

[Read the post](https://jpearson.blog/2025/07/04/calling-business-central-apis-without-a-client-secret/) · James Pearson (James Pearson) · 2025-07-04 · 1252 words · tier community · reviewed (checked by Opus)

> Explains how an Azure Function or Static Web App backend can call Business Central APIs without a client secret: the function gets a managed identity token, then exchanges it via a federated credential on the app registration for a token that BC accepts. The author notes this still works but a newer post describes a better way that calls BC directly from a managed identity.

## Key points

- Managed identities assigned to Azure resources can obtain access tokens without needing client secrets
- Federated credentials enable token exchange between the managed identity token and an app registration token
- An Entra Application must still be created in Business Central with appropriate permission sets
- Token exchange uses JWT bearer assertion to swap a managed identity token for an app registration token
- Establishes trust between managed identity issuer and app registration to authorize the token exchange

## Quotes

- "We need to exchange the token we've already got for a token issued for the app registration." (This explains the core mechanism: the managed identity token alone is insufficient; it must be exchanged for an app registration token that has Business Central permissions.)
- "It would be better if we had a solution that didn't rely on client secrets." (States the motivation: avoiding secrets eliminates expiration management, key vault dependencies, and credential compromise risks.)

## Context

- Features: Managed Identity Authentication, Federated Credentials, Service-to-Service Authentication, Token Exchange, Entra Application Integration

Source: James Pearson, community blog. Summary, key points and quotes are derived (CONTENT-NOTICE.md); read the original for the full text.