Der Artikel erklärt praxisnah, wie Business-Central-Webservices in C# authentifiziert werden, vergleicht Windows Auth, Basic Auth und OAuth2 und zeigt typische Fallstricke.
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:
Die Wahl der passenden Authentifizierung entscheidet nicht nur über Sicherheit, sondern auch über Stabilität und Zukunftsfähigkeit einer Schnittstelle.
Im Folgenden werden für den Business-Central-Webservice drei gängige Methoden gezeigt, zur Authentifizierung in der Praxis (C#) – inklusive kompakter Beispiele aus realen Projekten.
Je nach Szenario gibt es unterschiedliche Ansätze der Authentifizierung:
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).
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).
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).
Die Theorie ist das eine – die Praxis das andere.
Jede Methode birgt typische Stolperfallen, die in produktiven Umgebungen schnell kritisch werden können.
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.
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}
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.
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}
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.
Unser Geschäftsführer Tibor Csizmadia und unser Kundenbetreuer Jens Walter stehen Ihnen persönlich zur Verfügung. Profitieren Sie von unserer langjährigen Erfahrung und erhalten Sie eine kompetente Erstberatung in einem unverbindlichen Austausch.
