Business-Central-Webservice – Authentifizierung in der Praxis (C#)

Business-Central-Webservice – Authentifizierung in der Praxis (C#)
Michael W.
12/2025

Business-Central-Webservice – Authentifizierung in der Praxis (C#)

Viele Unternehmen stehen früher oder später vor der Herausforderung, Business Central (BC) über Webservices in externe Systeme zu integrieren. Spätestens dann taucht die Schlüsselfrage auf:

Wie authentifizieren wir uns richtig – sicher, stabil und zukunftsfähig?

Die Wahl der passenden Authentifizierung entscheidet nicht nur über Sicherheit, sondern auch über Stabilität und Zukunftsfähigkeit einer Schnittstelle.

Im Folgenden zeige ich drei gängige Methoden – inklusive kompakter C#-Beispiele aus der Praxis.

Authentifizierungsarten im Überblick

Je nach Szenario gibt es unterschiedliche Ansätze der Authentifizierung:

  1. Windows Auth (NTLM/Kerberos)
  1. Basic Auth mit Webdienst-Zugriffsschlüssel
  1. OAuth2 / Azure AD (Entra ID)

1.) Windows Auth (NTLM/Kerberos)

Der Klassiker in reinen On-Premise-Installationen.

Hier übernimmt der aktuell eingeloggte Windows-Benutzer automatisch die Anmeldung (Single-Sign-On).

Beispiel für die Implementierung:

1var handler = new HttpClientHandler {UseDefaultCredentials = true}; 
2using var client = new HttpClient(handler) BaseAdress = new Uri(baseUrl); 
3string result = await client.GetStringAsync(endpoint);

Vorteil: Sehr einfach umzusetzen, keine Credentials im Code.

Nachteil: Funktioniert nur intern (On-Premise).


2.) Basic Auth mit Webdienst-Zugriffsschlüssel

Diese Methode ist vor allem in hybriden Setups oder kleineren Projekten verbreitet.

Man authentifiziert sich mit Benutzername + Webdienstzugriffsschlüssel.

Beispiel für die Implementierung:

1var authString = Convert.ToBase64String(Encoding.UTF8.GetBytes($”{username}:{webkey}”));
2using var client = new HttpClient(handler) BaseAddress = new Uri(baseUrl);
3client.DefaultRequestHeaders.Authorization = new AuhtorizationHeaderValue(“basic”, authString);
4string result = await client.GetStringAsync(endpoint);

Vorteile: Zukunftssicher, kein Passwort im Code, volle Cloud-Kompatibilität.

Nachteil: Erfordert mehr Setup (Azure AD, App-Registrierung, Berechtigungen).

3.) OAuth2 / Azure AD (Entra ID)

Der moderne Standard. Für SaaS- und Cloud-Szenarien ist OAuth2 heute unverzichtbar.

Statt Benutzer-Credentials verwendet man eine Azure App Registration, um ein Access-Token für API-Aufrufe zu erhalten.

Beispiel für die Implementierung (mit MSAL):

1var app = ConfidentialClientApplicationBuilder.Create(clientId)
2.WithClientSecret(clientSecret)
3.WithAuthority($”https://login.microsoftonline.com/{tenantId}
4.Build();
5var result = await app.AcquireTokenForClient(new[] new https://api.businesscentral.dynamixs.com/default).ExecuteAsync();
6using var client = new HttpClient{BaseAddress = new Uri(baseUrl)};
7Client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(“Bearer”, result.AccessToken);
8String result = await client.GetStringAsync(“companies”);

Vorteile: Zukunftssicher, kein Passwort im Code, volle Cloud-Kompatibilität.

Nachteil: Erfordert initiales Setup (Azure AD, App-Registrierung, Berechtigungen).

Fallstricke und häufige Probleme in der Praxis

Die Theorie ist das eine – die Praxis das andere.

Jede Methode birgt typische Stolperfallen, die in produktiven Umgebungen schnell kritisch werden können.

Windows Auth – typische Probleme

Das Double-Hop-Problem:

Windows Authentication funktioniert nur zuverlässig, wenn alle Komponenten im gleichen Netzwerksegment liegen. Bei mehrschichtigen Systemen (Webserver → Application Server → BC-Server) scheitert die Weitergabe der Authentifizierung.

Firewall- und Proxy-Probleme:

NTLM und Kerberos sind für interne Netzwerke konzipiert.

VPN, Proxies oder externe Zugriffe stören häufig die Authentifizierung.

Basic Auth – ein unsicheres Auslaufmodell

Seit Oktober 2022 für BC Online deaktiviert.

Wer es dennoch versucht, erhält:

1{ 
2„error“: { 
3„code“: „Authenication_InvalidCredentials“, 
4„message“: „Web service acces key is no longer supported as authentication. Please use OAuth.” 
5} 
6} 

Warum problematisch?

Base64 ist keine Verschlüsselung. Benutzername + Schlüssel können leicht ausgelesen werden.

Beispiel:

1var authString = Convert.ToBase64String(
2Encoding.UTF8.GetBytes($"{username}:{webkey}") ); 

Diese Credentials sind praktisch im Klartext.

Empfehlung: Nur über HTTPS – und nur als kurzfristige Übergangslösung.

OAuth2 / Azure AD – häufige Fehlerquellen

Der Standard – aber nicht frei von Herausforderungen.

Token-Expiry (60–90 Minuten)

Ohne Refresh-Mechanismus bricht das System mitten am Tag zusammen.

Professionelles Token-Management (mit Puffer)

1{ 
2	private DateTime _tokenExpiry; 
3	private string _accessToken; 
4	private readonly object _lockObject = new object() 
5	public async Task<string> GetValidTokenAsync() 
6{ 
7		Lock (_lockObject) 
8	{ 
9	if (DateTime.Utc.Now.AddMinutes(5) >= _tokenExpiry) 
10	{ 
11		Return RefreshTokenAsync();} 
12	} 
13	private async Task<string>RefreshTokenAsync() 
14	{ 
15		try 
16		{ 
17		Var result = await app.AcquireTokenForClient(scopes).ExecuteAsync(); 
18		_accessToken = result.AccessToken; 
19		_tokenExpiry = result.ExpiresOn.DateTime; 
20		return _accessToken; 
21	} 
22	catch (msalServiceException ex) 
23	{ 
24			throw new AuthenticationException($”Token Refresh Fehlgeschlagen: {ex.ErrorCode}”, ex); 
25		} 
26	} 
27} 

Fazit

Trotz verschiedener möglicher Ansätze führt langfristig kein Weg an OAuth2 vorbei.

Ob On-Premise oder Cloud – OAuth2 bietet Stabilität, Sicherheit und Zukunftsfähigkeit.

Wer die beschriebenen Fallstricke kennt und von Anfang an berücksichtigt, kann robuste und zuverlässige Integrationen in Business Central realisieren.

Besonders das Thema Token-Management entscheidet über Erfolg oder Ausfall einer Schnittstelle.

Wenn Sie aktuell vor Integrationsherausforderungen stehen oder eine zuverlässige Authentifizierungslösung für Business Central benötigen, lohnt sich ein Blick in Ihre bestehenden Schnittstellen. Kleine Anpassungen machen oft einen großen Unterschied.

→ Kontaktieren Sie uns gerne für eine kurze Einschätzung oder ein technisches Sparring zu Ihrem aktuellen System.

No items found.
Foto von Michael
Michael W.

Mehr zum Thema

Pfeil nach rechts (Verlinkung)
Strategy Pattern in C#: Flexibler & wartbarer Code
10/2025

Strategy Pattern in C#: Flexibler & wartbarer Code

Blauer Pfeil nach rechts (Verlinkung)
csharp-it-abteilung-vorteile-zukunftssichere-loesung
07/2025

C# für Unternehmen: Vorteile für IT-Abteilungen & Entwicklung

Blauer Pfeil nach rechts (Verlinkung)
FluentValidation in Blazor: Validierungslogik mit Custom Rules und Feldern
04/2025

Blazor FluentValidation | C# Validation Best Practices

Blauer Pfeil nach rechts (Verlinkung)
Liskov Principle: Schnittstellenfehler & Sicherheitslücken vermeiden
12/2024

Solid Reihe - Liskov Substitution Principle

Blauer Pfeil nach rechts (Verlinkung)

Lassen Sie uns gemeinsam wachsen.

Devware GmbH verpflichtet sich, Ihre Privatsphäre zu schützen. Wir benötigen Ihre Kontaktinformationen, um Sie bezüglich unserer Produkte und Dienstleistungen zu kontaktieren. Mit Klick auf Absenden geben Sie sich damit einverstanden. Weitere Informationen finden Sie unter Datenschutz. Ihre Daten behandeln wir vertraulich. Versprochen.
Vielen Dank für Ihr Vertrauen.
Unser Team prüft Ihre Anfrage sorgfältig und meldet sich in der Regel innerhalb von 48 Stunden bei Ihnen zurück.
Falls es besonders eilig ist, erreichen Sie uns auch telefonisch:
+ 49 (0) 202 478 269 0.
Da ist etwas schief gegangen beim Absenden des Formulars.