by Steve Endow
[This blog post was 100% human written. None of this post was drafted or written by an AI.]
We received an email from a partner asking me to help someone with a BC Web API authentication issue.
"We are getting an authentication error with our API web access key when trying to connect to the customer's BC environment."
Say what? This is in July 2026. Business Central hasn't had web access keys since 2022. Red flag #1.
I was busy, so I assumed someone else helped resolve the issue.
The next day, we get another email from the partner. We learn that it is a third party ecommerce provider who is having the issue. The partner provides a link to a video.
I hover over the link in the email. It points to a Google Drive. I click on it and a video opens in my browser. Without any authentication. Just keep this in mind for few moments...
The video shows the authentication screen in the Postman application. There is no audio. The person is apparently trying to configure an OAuth connection to the Business Central Web API.
The Postman URL shows "ODataV4". In July 2026. Red flag #2.
The video shows a mouse highlighting the elements of the URL, the auth endpoints, the client ID, etc. The video then switches to Notepad++, showing the OAuth connection information.
Client ID
Secret Value
The file path in Notepad++ shows that this information is saved in a TXT file in the user's local Documents folder. Red flag #3.
The user has the secret value labeled as the Client ID, and the Client ID GUID labeled as the secret value. They then proceed to try pasting values the incorrect values into the wrong fields in Postman.
So let me get this straight:
1. This person stores customer API keys in a text file on their computer
2. They then record a video showing an API key on screen
3. They then upload that video to Google Drive
4. They then share an unauthenticated public link to the video via email
5. The partner then forwards that email, with the unauthenticated link, to multiple people
So many red flags here it's like a red flag convention.
If you are a Business Central consultant or developer, or any technology consultant or developer for that matter, the gross negligence demonstrated by this person should be obvious.
The employee who exposed the API key apparently works for "a B2B ecommerce platform provider that builds, hosts, and supports ecommerce sites for manufacturers, distributors, and wholesalers. It emphasizes ERP integration, complex pricing, customer portals, quotes, payments, and other B2B workflows."
If you ever wondered why there are so many data breaches, this is Exhibit A.
Here's the problem:
Customer says "We use this ecommerce provider. They need to integrate without ERP system. Provide them with API access, BC partner."
Once the BC partner provides the API info to the third party, you have no idea what that third party is doing with the key. If the key is compromised, how would you know? How many customers and partners actively monitor and audit activity related to API access?
As a first step to try and address this, I figured I would try the "educational" approach.
Educate the partner. Educate the customer. Educate the recklessly incompetent ecommerce provider.
 |
| Education and CYA |
Why? Other than being the responsible thing to do, I do not want to be involved in a lawsuit because I provided an API key to someone who caused a customer's Business Central environment to be compromised.
Granting BC API access should be formally authorized by the customer. They should acknowledge the risks. They should validate the competence of the third party. They should have an API access procedure.
The form requires the third party to provide documented API secure handling procedures and minimum required ERP access. It informs the customer. It documents the process.
 |
| Requester must acknowledge responsibility |
 |
| The customer is responsible |
 |
| The request is formally documented |
Given the negligence demonstrated in the video, the ecommerce organization clearly lacks any culture of security, training, and supervision. So we'll see how this goes.
I'll provide the form to the BC partner and it will be their responsibility to do the right thing by informing the customer of the security incident and having all parties complete the form.
Steve Endow is a Microsoft MVP in Los Angeles. He works with Dynamics 365 Business Central and related technologies.
No comments:
Post a Comment
All comments must be reviewed and approved before being published. Your comment will not appear immediately.