App-Schnittstellen: SSO, CRM und API-Strategie für Business-Apps

Carola Schulte, App-Entwicklerin

“Die App muss mit unserem CRM sprechen” - Der Satz, der aus jedem MVP ein Enterprise-Projekt macht. Integration ist kein Nice-to-Have, sondern Pflicht bei Business-Apps. Aber: Falsch geplant, explodieren Kosten (+150%) und Timeline (+6 Monate).

Als Software-Architektin mit 25+ Jahren Erfahrung zeige ich Ihnen, wie Sie Apps richtig integrieren: SSO (SAML, OAuth, LDAP), CRM/ERP-Sync, API-Strategien (REST vs. GraphQL), Security (OAuth-Tokens, TLS-Pinning) - mit konkreten Zahlen aus Wächterkontrollsystemen, Inventur-Apps und NFC-Projekten.

🔔 WICHTIG: Alle Preise verstehen sich netto (zzgl. 19% USt.). DE-Sätze; Offshore/NE-EU abweichend.

TL;DR - Die Essenz

Integrations-Typ	Komplexität	Typische Kosten	Use Case
SSO (Single Sign-On)	Mittel	3.000-8.000 €	OAuth, SAML, LDAP/Active Directory
CRM-Integration (Standard)	Mittel	5.000-15.000 €	Salesforce, HubSpot, Pipedrive (REST-APIs)
CRM-Integration (Custom)	Hoch	15.000-40.000 €	Legacy-Systeme, SOAP, Custom-Protokolle
ERP-Integration (Standard)	Hoch	10.000-25.000 €	SAP, Microsoft Dynamics, DATEV (REST/SOAP)
ERP-Integration (Custom)	Sehr Hoch	25.000-60.000 €	On-Premise SAP, Custom-DBs, Mainframes
Datenbank-Direktzugriff	Niedrig-Mittel	2.000-6.000 €	MSSQL, PostgreSQL, Oracle (Read-Only empfohlen)
WebSockets (Realtime)	Mittel	4.000-10.000 €	Chat, Live-Tracking, Notifications

Goldene Regel: Integration kostet 10-30% der Entwicklungskosten. Bei Legacy-Systemen (SAP, Mainframe) kann es 50-100% sein.

Hinweis: Alle Preise netto, DACH-Bandbreiten, abhängig von Scope/Seniority.

Warum Integration Pflicht ist (keine Insellösung)

Problem: “Wir haben schon ein CRM, ERP, HR-System - warum noch eine App?”

Antwort: Weil Mobile-First für Außendienst, Field-Service, Logistik Pflicht ist. Aber: Die App muss mit bestehenden Systemen sprechen, sonst entsteht Datensilos.

Das Datensilos-Problem

Ohne Integration:

Wächterkontrolle-App → SQLite (lokal)
CRM (Salesforce) → Cloud
ERP (SAP) → On-Premise

→ 3 separate Datenquellen
→ Manuelle Daten-Migration (Excel-Export/Import)
→ Keine Echtzeit-Synchronisation
→ Fehleranfällig (Duplikate, veraltete Daten)

Mit Integration:

Wächterkontrolle-App → REST API → CRM/ERP
→ Automatische Synchronisation (Echtzeit oder Batch)
→ Single Source of Truth (CRM = Master)
→ Keine manuellen Exports
→ Weniger Fehler (API validiert Daten)

Business-Impact:

✅ Zeitersparnis: 5-10 Stunden/Monat (keine Excel-Exporte)
✅ Fehlerreduktion: -80% (API-Validierung vs. manuelle Eingabe)
✅ Echtzeit-Daten: Manager sehen Check-Ins sofort (nicht am nächsten Tag)
✅ Compliance: DSGVO-Löschpflicht automatisch (CRM löscht → App löscht)

Kosten-Nutzen-Rechnung:

Integration: 12.000 € (einmalig)
Zeitersparnis: 8 Stunden/Monat × 50 €/Stunde = 400 €/Monat
→ ROI nach 30 Monaten

Bei 5 Jahren: 24.000 € Ersparnis - 12.000 € Integration = 12.000 € Gewinn

Problem: User hat 5 Apps (CRM, ERP, HR, Inventur, Wächterkontrolle) → 5 verschiedene Logins → Passwort-Hölle.

Lösung: SSO (Single Sign-On) - User loggt sich einmal ein (z.B. in Active Directory) → alle Apps nutzen denselben Login.

SSO-Protokolle im Vergleich

Protokoll	Komplexität	Use Case	Kosten (Implementierung)
OAuth 2.0	Niedrig-Mittel	Social Login (Google, Microsoft), Cloud-Apps	3.000-6.000 €
SAML 2.0	Mittel-Hoch	Enterprise (Active Directory, Okta, Azure AD)	5.000-10.000 €
LDAP	Mittel	On-Premise (Active Directory, OpenLDAP)	4.000-8.000 €
OpenID Connect	Niedrig-Mittel	Modern SSO (basiert auf OAuth 2.0)	3.000-6.000 €

OAuth 2.0: Der Standard für Cloud-Apps

Prinzip: User autorisiert App, auf Name/E-Mail zuzugreifen (z.B. “Mit Google anmelden”).

Flow:

1. User klickt "Mit Google anmelden"
2. App öffnet Google-Login (Browser/WebView)
3. User loggt sich bei Google ein
4. Google gibt **Access-Token** an App
5. App nutzt Token, um User-Daten abzurufen (Name, E-Mail, Foto)

Code-Beispiel (Flutter + OAuth 2.0):

import 'package:google_sign_in/google_sign_in.dart';

final GoogleSignIn _googleSignIn = GoogleSignIn(
  scopes: ['email', 'profile'],
);

Future<void> signInWithGoogle() async {
  try {
    final account = await _googleSignIn.signIn();
    if (account == null) return; // User hat abgebrochen

    final auth = await account.authentication;
    final accessToken = auth.accessToken;

    // Access-Token an Backend senden
    await api.post('/auth/google', {
      'token': accessToken,
    });

    // User ist eingeloggt
  } catch (e) {
    print('Login fehlgeschlagen: $e');
  }
}

Kosten: 3.000-5.000 € (OAuth-Implementierung + Backend-Integration)

Vorteile:

✅ Einfach (User kennt Google/Microsoft-Login)
✅ Keine Passwort-Verwaltung (Google/Microsoft übernimmt das)
✅ Schneller Onboarding (1-Click-Login)

Nachteile:

❌ Abhängigkeit von externem Provider (Google down = kein Login)
❌ Datenschutz-Bedenken (Google sieht, wer sich einloggt)

SAML 2.0: Enterprise-Standard

Prinzip: User loggt sich in Identity Provider (z.B. Azure AD, Okta) ein → IdP gibt SAML-Assertion an App → App vertraut IdP.

Use Case: Große Firmen mit Active Directory (500+ User).

Flow:

1. User öffnet App
2. App redirect zu Azure AD (Identity Provider)
3. User loggt sich bei Azure AD ein (Windows-Login)
4. Azure AD generiert SAML-Assertion (XML mit User-Daten)
5. App validiert SAML-Assertion (Signatur prüfen)
6. User ist eingeloggt

Kosten: 5.000-10.000 € (SAML-Implementierung + Azure AD-Setup)

Vorteile:

✅ Enterprise-Standard (Active Directory-Integration)
✅ Zentralisierte User-Verwaltung (IT-Admin verwaltet Zugriffe)
✅ Sicherheit (SAML-Assertion signiert)

Nachteile:

❌ Komplex (XML-Parsing, Signatur-Validierung)
❌ Teurer als OAuth (mehr Entwicklungsaufwand)

SAML-Praxis-Tipp: Nutze Library wie onelogin/python-saml (Python) oder saml2-js (Node.js) - niemals selbst implementieren (Security-Risiko).

LDAP: On-Premise Active Directory

Prinzip: App verbindet sich direkt mit Active Directory (LDAP-Protokoll) → prüft Username/Password.

Use Case: On-Premise-Firmen ohne Cloud (keine Azure AD, kein Okta).

Code-Beispiel (Python + LDAP):

import ldap

def authenticate_ldap(username, password):
    server = 'ldap://dc.firma.local'
    bind_dn = f'CN={username},OU=Users,DC=firma,DC=local'

    try:
        conn = ldap.initialize(server)
        conn.simple_bind_s(bind_dn, password)
        # Login erfolgreich
        return True
    except ldap.INVALID_CREDENTIALS:
        # Falsches Passwort
        return False

Kosten: 4.000-8.000 € (LDAP-Integration + VPN-Setup für App)

Vorteile:

✅ On-Premise (keine Cloud-Abhängigkeit)
✅ Direkter Active Directory-Zugriff

Nachteile:

❌ VPN nötig (App muss ins Firmennetzwerk)
❌ Passwort-Transmission (App kennt Passwort → Security-Risiko bei Compromise)
❌ Nicht für Public-Apps geeignet (nur Firmen-intern)

Security-Warnung: LDAP überträgt Passwort → TLS/SSL Pflicht. Besser: SAML/OAuth (Passwort bleibt bei IdP).

CRM-Integration: Salesforce, HubSpot, Custom

Use Case: Wächterkontrolle-App → Check-Ins ins CRM syncen (Salesforce), damit Vertrieb sieht, welche Kunden besucht wurden.

Salesforce-Integration (REST API)

Salesforce bietet REST API → einfach zu integrieren.

Flow:

1. Wächter macht Check-In (App → SQLite lokal)
2. App syncet zu Backend (REST API)
3. Backend syncet zu Salesforce (REST API)
   → Erstellt "Task" in Salesforce (Visit-Log)

Code-Beispiel (Python + Salesforce REST API):

from simple_salesforce import Salesforce

sf = Salesforce(
    username='user@firma.com',
    password='password',
    security_token='token',
    domain='login'  # oder 'test' für Sandbox
)

# Check-In als Task in Salesforce erstellen
sf.Task.create({
    'Subject': 'Wächter Check-In: Objekt A',
    'Status': 'Completed',
    'ActivityDate': '2025-11-01',
    'WhoId': 'Kontakt-ID',  # Salesforce Lead/Contact ID
    'Description': 'GPS: 48.1351, 11.5820 | Foto: https://...'
})

Kosten: 8.000-12.000 € (Salesforce-Integration + OAuth-Setup)

Vorteile:

✅ Gut dokumentierte API (Salesforce Developer Docs)
✅ OAuth 2.0 (keine Passwörter in Code)
✅ Sandbox (Test-Environment vor Production)

Nachteile:

❌ Rate-Limits (max. 15.000 API-Calls/24h bei Standard-Lizenz)
❌ Kosten (Salesforce API-Zugriff ab Professional-Edition = 75 €/User/Monat)

HubSpot-Integration (REST API)

HubSpot = CRM für KMU (günstiger als Salesforce).

Code-Beispiel (Node.js + HubSpot API):

const hubspot = require('@hubspot/api-client');

const client = new hubspot.Client({ accessToken: 'YOUR_ACCESS_TOKEN' });

// Contact erstellen (Lead)
await client.crm.contacts.basicApi.create({
  properties: {
    email: 'kunde@firma.de',
    firstname: 'Max',
    lastname: 'Mustermann',
    phone: '+49 123 456789',
    company: 'Muster GmbH',
  }
});

// Deal erstellen (Opportunity)
await client.crm.deals.basicApi.create({
  properties: {
    dealname: 'App-Projekt: Inventur-Scanner',
    amount: '45000',
    dealstage: 'qualifiedtobuy',
  }
});

Kosten: 5.000-10.000 € (HubSpot-Integration)

Vorteile:

✅ Einfache API (REST, gut dokumentiert)
✅ Kostenlos (HubSpot Free hat API-Zugriff)
✅ Webhooks (HubSpot benachrichtigt App bei Änderungen)

Nachteile:

❌ Weniger Features als Salesforce (für Enterprise oft zu simpel)

Custom-CRM-Integration (Legacy-Systeme)

Problem: Firma nutzt Custom-CRM (selbst gebaut, 15 Jahre alt) → keine REST API, nur SOAP oder Datenbank-Direktzugriff.

Lösungen:

Option 1: SOAP-Wrapper bauen

from zeep import Client

client = Client('http://crm.firma.local/api?wsdl')
result = client.service.CreateContact(
    FirstName='Max',
    LastName='Mustermann',
    Email='max@firma.de'
)

Kosten: 15.000-25.000 € (SOAP-Integration + Reverse-Engineering)

Option 2: Datenbank-Direktzugriff (Read-Only empfohlen)

import pyodbc

conn = pyodbc.connect(
    'DRIVER={SQL Server};SERVER=crm-db.firma.local;'
    'DATABASE=CRM;UID=app_user;PWD=password'
)

cursor = conn.cursor()
cursor.execute("SELECT * FROM Contacts WHERE Email = ?", 'max@firma.de')
contact = cursor.fetchone()

Kosten: 8.000-15.000 € (DB-Integration + Schema-Reverse-Engineering)

⚠️ Security-Warnung: Direkter DB-Zugriff = Read-Only empfohlen (Write = Risiko von Data-Corruption). Besser: CRM baut eigene REST API.

Option 3: Middleware bauen (API-Gateway)

App → REST API (Custom-Middleware) → SOAP/DB → Legacy-CRM

Kosten: 20.000-40.000 € (Custom-Middleware + Testing)

Vorteil: App spricht nur REST → Legacy-System austauschbar (ohne App zu ändern).

ERP-Integration: SAP, Microsoft Dynamics, DATEV

Use Case: Eine Inventur-App scannt Artikel per Barcode, das Backend übergibt die Bestände ans ERP, damit Buchhaltung und Bestandsführung ohne Doppelerfassung weiterlaufen.

Die drei Systeme, die mir in Projekten am häufigsten begegnen, unterscheiden sich vor allem in der Schnittstelle: SAP bietet mit OData eine REST-ähnliche API, ist aber in Dokumentation und Antwortzeiten der schwerste Brocken (20.000-35.000 € (SAP-Integration + Consultant-Support)). Microsoft Dynamics 365 kommt mit einer sauberen REST-API und ist deutlich zugänglicher (12.000-20.000 € (Dynamics-Integration)). DATEV ist Pflicht, sobald ein Steuerberater im Spiel ist, arbeitet aber teils noch mit SOAP und veralteter Dokumentation (15.000-25.000 € (DATEV-Integration + Steuerberater-Konsultation)).

Wie die Anbindung an ERP, Warenwirtschaft und Altsysteme technisch abläuft, welche Wege es gibt (direkte API, Middleware, Datei-Export) und woran solche Projekte scheitern, steht ausführlich im Beitrag App an ERP & Altsysteme anbinden: SAP, DATEV, Warenwirtschaft. Hier bleibt der Blick auf der Gesamtstrategie: SSO, CRM und ERP müssen zusammen geplant werden, sonst entsteht die Insellösung durch die Hintertür.

API-Strategien: REST vs. GraphQL vs. WebSockets

REST API: Der Standard

Prinzip: HTTP-basiert (GET, POST, PUT, DELETE).

Beispiel:

GET  /api/users/123         → User abrufen
POST /api/users             → User erstellen
PUT  /api/users/123         → User aktualisieren
DELETE /api/users/123       → User löschen

Vorteile:

✅ Einfach (jeder versteht HTTP)
✅ Stateless (keine Sessions nötig)
✅ Cacheable (Browser cached GET-Requests)

Nachteile:

❌ Over-Fetching (GET /api/users/123 gibt alle Felder zurück, auch wenn nur Name gebraucht wird)
❌ Under-Fetching (User + Posts → 2 Requests nötig: GET /users/123, GET /users/123/posts)

REST-Best-Practices:

1. Versionierung: /api/v1/users (nicht /api/users)
2. Pagination: /api/users?page=1&limit=20
3. Filtering: /api/users?role=admin
4. HTTP-Status-Codes: 200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Server Error
5. JSON (nicht XML): {"name": "Max"}

GraphQL: Flexibler, aber komplexer

Prinzip: Client fragt genau die Daten ab, die er braucht.

Beispiel:

# Client fragt nur Name + E-Mail ab (nicht alle Felder)
query {
  user(id: 123) {
    name
    email
  }
}

# Response
{
  "data": {
    "user": {
      "name": "Max Mustermann",
      "email": "max@firma.de"
    }
  }
}

Vorteil: Nested-Queries (User + Posts in 1 Request)

query {
  user(id: 123) {
    name
    posts {
      title
      createdAt
    }
  }
}

Vorteile:

✅ Kein Over-/Under-Fetching (Client holt nur was er braucht)
✅ Typisiert (GraphQL-Schema definiert Typen)
✅ Self-Documenting (GraphQL Playground zeigt alle Queries)

Nachteile:

❌ Komplex (GraphQL-Server aufwändiger als REST)
❌ Caching schwierig (HTTP-Cache funktioniert nicht)
❌ Overkill für einfache APIs (REST reicht meist)

Wann GraphQL nutzen?

✅ Mobile-Apps mit limitierter Bandbreite (nur nötige Daten fetchen)
✅ Viele verschiedene Clients (Web, Mobile, Desktop) mit unterschiedlichen Daten-Needs
❌ Nicht bei einfachen CRUD-APIs (REST ist einfacher)

WebSockets: Realtime-Kommunikation

Prinzip: Bidirektionale Verbindung (Server kann Client pushen, nicht nur umgekehrt).

Use Cases:

Chat-Apps (Nachrichten instant zeigen)
Live-Tracking (Wächter-Position in Echtzeit)
Notifications (Server pushed Notification an App)

Code-Beispiel (Flutter + WebSockets):

import 'package:web_socket_channel/web_socket_channel.dart';

final channel = WebSocketChannel.connect(
  Uri.parse('wss://api.firma.de/ws'),
);

// Nachrichten empfangen
channel.stream.listen((message) {
  print('Server sagt: $message');
});

// Nachricht senden
channel.sink.add('Hallo Server');

Kosten: 4.000-10.000 € (WebSocket-Server + Scaling)

Vorteile:

✅ Echtzeit (keine Polling nötig: GET /messages alle 5 Sekunden)
✅ Bidirektional (Server kann Client pushen)

Nachteile:

❌ Stateful (Server muss Connection halten → Skalierung schwierig)
❌ Firewall-Probleme (manche Firmen-Firewalls blocken WebSockets)

Alternative: Server-Sent Events (SSE) - einfacher als WebSockets, aber unidirektional (Server → Client).

Real Cases: Integration in der Praxis

Case 1: Wächterkontrollsystem (CRM-Sync)

Anforderung:

Check-Ins (GPS, NFC, Fotos) ins CRM syncen (Salesforce)
Vertrieb sieht, welche Objekte besucht wurden
Manager sieht Check-Ins in Echtzeit

Technische Lösung:

Wächter-App (Flutter) → Backend (Node.js) → Salesforce REST API

Flow:
1. Wächter macht Check-In (GPS + NFC-Tag)
2. App speichert lokal (SQLite) + sendet zu Backend
3. Backend erstellt "Task" in Salesforce (Visit-Log)
4. Vertrieb sieht Check-In in Salesforce (Activity-Timeline)

Code-Snippet (Backend → Salesforce):

const jsforce = require('jsforce');

const conn = new jsforce.Connection({
  oauth2: {
    clientId: process.env.SF_CLIENT_ID,
    clientSecret: process.env.SF_CLIENT_SECRET,
  }
});

await conn.login(process.env.SF_USERNAME, process.env.SF_PASSWORD);

// Check-In als Task erstellen
await conn.sobject('Task').create({
  Subject: `Check-In: ${checkin.location}`,
  Status: 'Completed',
  ActivityDate: checkin.timestamp,
  Description: `GPS: ${checkin.gps} | NFC: ${checkin.nfc_tag}`,
});

Kosten Integration: 10.000 € (Salesforce REST API + OAuth + Testing)

Learnings:

✅ Salesforce-Sandbox essentiell (Testing vor Production)
⚠️ Rate-Limits beachten (max. 15.000 API-Calls/24h)
✅ Retry-Logic wichtig (Salesforce manchmal down)

Case 2: Inventur-Scanner (ERP-Export)

Anforderung:

Gescannte Artikel (1000+) ins ERP exportieren (SAP)
Bestand in SAP aktualisieren
CSV-Export als Fallback (falls SAP down)

Technische Lösung:

Inventur-App (Flutter) → Backend (Python) → SAP OData API

Flow:
1. Scanner scannt 1000 Artikel (Barcode)
2. App speichert lokal (SQLite)
3. User klickt "Export zu SAP"
4. Backend batched Requests (50 Artikel/Request)
5. SAP aktualisiert Bestand

Batch-Request (Performance-Optimierung):

# ❌ Langsam: 1000 einzelne Requests
for article in articles:
    sap_api.update_stock(article)

# ✅ Schnell: Batch-Request (50 Artikel auf einmal)
batches = [articles[i:i+50] for i in range(0, len(articles), 50)]
for batch in batches:
    sap_api.batch_update_stock(batch)

Kosten Integration: 22.000 € (SAP OData API + Consultant + Testing)

Learnings:

✅ Batch-Requests Pflicht (1000 einzelne Requests = zu langsam)
⚠️ SAP-Consultant nötig (SAP-Dokumentation unverständlich)
✅ CSV-Fallback wichtig (SAP manchmal instabil)

Case 3: Mensa-NFC-App (LDAP-SSO + Studenten-DB)

Anforderung:

SSO mit Uni-Active-Directory (LDAP)
Studenten-Daten aus Uni-DB laden (PostgreSQL)
Check-Ins speichern (lokale DB)

Technische Lösung:

Mensa-App (Flutter) → Backend (Python) → LDAP (Active Directory) + PostgreSQL

Flow:
1. Student loggt sich ein (Uni-Login)
2. Backend prüft Credentials via LDAP
3. Backend lädt Studenten-Daten aus PostgreSQL
4. Check-In wird gespeichert (PostgreSQL)

LDAP-Integration:

import ldap

def authenticate(username, password):
    conn = ldap.initialize('ldap://ldap.uni.de')
    bind_dn = f'uid={username},ou=students,dc=uni,dc=de'
    try:
        conn.simple_bind_s(bind_dn, password)
        return True
    except ldap.INVALID_CREDENTIALS:
        return False

Kosten Integration: 6.500 € (LDAP-SSO + PostgreSQL-Read-Access)

Learnings:

✅ LDAP einfacher als SAML (Uni hatte kein SAML)
⚠️ VPN nötig (LDAP nur im Uni-Netz erreichbar)
✅ PostgreSQL Read-Only (kein Write-Zugriff auf Uni-DB)

Kosten-Übersicht: Was kostet Integration wirklich?

Integrations-Kosten nach Komplexität

Integrations-Typ	Aufwand (Tage)	Kosten (bei 1.200 €/Tag)	Timeline
SSO (OAuth 2.0)	3-5 Tage	3.600-6.000 €	1-2 Wochen
SSO (SAML 2.0)	5-8 Tage	6.000-9.600 €	2-3 Wochen
CRM (Salesforce REST)	6-10 Tage	7.200-12.000 €	2-3 Wochen
CRM (Custom SOAP)	12-20 Tage	14.400-24.000 €	3-5 Wochen
ERP (SAP OData)	15-25 Tage	18.000-30.000 €	4-6 Wochen
ERP (Custom DB)	8-15 Tage	9.600-18.000 €	2-4 Wochen
WebSockets (Realtime)	4-8 Tage	4.800-9.600 €	1-3 Wochen

Gesamt-Budget-Regel: Integration = 10-30% der Entwicklungskosten.

Beispiel:

App-Entwicklung: 60.000 €
+ SSO (OAuth): 5.000 €
+ CRM (Salesforce): 10.000 €
Gesamt: 75.000 € (Integration = 20% Aufschlag)

Bei Legacy-Systemen (SAP On-Premise, Mainframe): Integration kann 50-100% der Entwicklungskosten sein.

Security: OAuth-Tokens, API-Keys, TLS-Pinning

API-Keys: Einfach, aber unsicher

Problem: API-Key im Code hardcoded → jeder mit APK/IPA kann Key extrahieren.

// ❌ FALSCH: API-Key hardcoded
final apiKey = 'sk_live_1234567890abcdef';

Lösung: Environment-Variables + Backend-Proxy

// ✅ RICHTIG: API-Key nur im Backend
final response = await http.post(
  '/api/crm/create-contact',  // Backend-Endpoint
  body: contactData,
);

// Backend macht Request mit API-Key
app.post('/api/crm/create-contact', async (req, res) => {
  const apiKey = process.env.CRM_API_KEY;  // Aus Environment
  await crmApi.createContact(req.body, apiKey);
});

OAuth 2.0 Tokens: Best Practice

Flow:

1. App fordert Access-Token an (OAuth-Flow)
2. Backend gibt Access-Token (Lebensdauer: 1 Stunde)
3. App nutzt Token für API-Requests
4. Token läuft ab → App fordert neuen Token an (Refresh-Token)

Code-Beispiel (Token-Refresh):

String accessToken = await storage.read(key: 'access_token');
String refreshToken = await storage.read(key: 'refresh_token');

// Access-Token abgelaufen? Refresh!
if (isExpired(accessToken)) {
  final response = await http.post('/auth/refresh', body: {
    'refresh_token': refreshToken,
  });
  accessToken = response.data['access_token'];
  await storage.write(key: 'access_token', value: accessToken);
}

Security-Best-Practices:

✅ Access-Token kurzlebig (1 Stunde, nicht 1 Jahr)
✅ Refresh-Token sicher speichern (Keychain/KeyStore, nicht SharedPreferences)
✅ HTTPS Pflicht (Token nie über HTTP senden)

TLS-Pinning: Schutz vor Man-in-the-Middle

Problem: Angreifer fälscht TLS-Zertifikat → liest API-Requests mit.

Lösung: TLS-Pinning → App vertraut nur bestimmtem Zertifikat.

Code-Beispiel (Flutter + TLS-Pinning):

import 'package:http/io_client.dart';
import 'dart:io';

final client = IOClient(
  HttpClient()..badCertificateCallback = (cert, host, port) {
    // Nur Zertifikat mit bestimmtem Fingerprint erlauben
    return cert.sha1.toString() == 'SHA1_FINGERPRINT_DES_SERVERS';
  },
);

Kosten: +1-2 Tage (TLS-Pinning-Setup + Testing)

Vorteil: Schutz vor Man-in-the-Middle-Attacken.

Nachteil: Zertifikat-Rotation kompliziert (neues Zertifikat → App-Update nötig).

Häufige Integrations-Fehler

Fehler 1: Hardcoded Credentials

Problem:

// ❌ API-Key direkt im Code
final apiKey = 'sk_live_1234567890abcdef';
await crmApi.createContact(apiKey, data);

Lösung:

// ✅ Backend-Proxy (API-Key nur im Backend)
await http.post('/api/crm/create-contact', body: data);

Fehler 2: Keine Retry-Logic

Problem: CRM-API ist down (500 Server Error) → App crasht.

Lösung: Exponential Backoff

Future<Response> apiCallWithRetry() async {
  int retries = 0;
  while (retries < 3) {
    try {
      return await http.post('/api/crm/contact');
    } catch (e) {
      retries++;
      await Future.delayed(Duration(seconds: 2 ** retries));  // 2s, 4s, 8s
    }
  }
  throw Exception('API nach 3 Versuchen nicht erreichbar');
}

Fehler 3: Keine Timeout-Limits

Problem: SAP-API antwortet nicht → App hängt 5 Minuten.

Lösung: Timeout setzen

final response = await http
  .post('/api/sap/update-stock')
  .timeout(Duration(seconds: 30));  // Max. 30 Sekunden warten

Fehler 4: Keine Pagination bei großen Datensets

Problem: GET /users gibt 10.000 User zurück → App crasht (Out-of-Memory).

Lösung: Pagination

// ✅ Nur 50 User pro Request
final response = await http.get('/api/users?page=1&limit=50');

Checkliste: Integrations-Strategie definieren

Vor Projektstart

Welche Systeme integrieren? CRM, ERP, HR, Custom?
API-Typen klären: REST, SOAP, GraphQL, DB-Direktzugriff?
SSO-Anforderung? OAuth, SAML, LDAP, oder eigene User-DB?
Datenfluss definieren: App → Backend → CRM (unidirektional) oder bidirektional?
Legacy-Systeme? SAP, Mainframe, Custom-SOAP → Consultant nötig?

Tech-Entscheidungen

API-Strategie: REST (Standard), GraphQL (Mobile-optimiert), WebSockets (Realtime)?
Auth-Strategie: OAuth 2.0 (Cloud), SAML (Enterprise), LDAP (On-Premise)?
Backend-Proxy: Ja (API-Keys sicher) oder direkt aus App (nur bei OAuth)?
Retry-Logic: Exponential Backoff implementiert?
Timeout-Limits: Alle API-Calls haben Timeout (z.B. 30 Sekunden)?

Security

TLS-Pinning: Bei sensiblen Daten (Banking, Health)?
Token-Storage: Keychain/KeyStore (nicht SharedPreferences)?
API-Keys: Nie hardcoded, nur Backend oder Environment-Variables?
HTTPS Pflicht: Alle API-Calls über HTTPS (nie HTTP)?

Nach Integration

Load-Testing: API-Calls mit 100+ parallelen Requests getestet?
Error-Handling: Alle API-Fehler (400, 401, 500) behandelt?
Monitoring: API-Response-Times überwacht (z.B. mit Sentry)?
Dokumentation: API-Endpoints dokumentiert (für Wartung)?

Fazit: Integration ist Pflicht, aber planbar

Die wichtigsten Learnings:

✅ Integration kostet 10-30% der Entwicklungskosten (bei Legacy: 50-100%)
✅ SSO spart Zeit (1 Login für alle Apps → bessere UX)
✅ REST reicht meist (GraphQL nur bei Mobile-Optimierung nötig)
✅ Backend-Proxy schützt (API-Keys nie in App hardcoden)
✅ Retry-Logic Pflicht (APIs sind manchmal down)
✅ Consultant bei Legacy (SAP, Mainframe → nicht alleine probieren)
✅ Datensilos vermeiden (Integration = Single Source of Truth)

Goldene Regel: Integration in Discovery-Phase planen, nicht nach 6 Monaten Entwicklung (“Ach ja, die App muss noch mit SAP sprechen…”).

Lassen Sie uns über Ihre Integrations-Strategie sprechen

Sie wissen nicht, wie Sie Ihre App mit CRM/ERP/SSO verbinden sollen? In einem kostenlosen Erstgespräch (30 Min):

✅ Analysieren wir Ihre bestehenden Systeme (CRM, ERP, HR, Custom)
✅ Definieren wir die optimale API-Strategie (REST, GraphQL, SOAP)
✅ Klären wir SSO-Anforderungen (OAuth, SAML, LDAP)
✅ Schätzen wir Integrations-Kosten transparent (10-30% Aufschlag)

Keine Buzzwords, keine Fantasie-Zahlen - nur ehrliche Einschätzung aus 25+ Jahren Praxis.

Termin vereinbaren →

Weitere hilfreiche Artikel:

Ihr App-Projekt besprechen?

Lassen Sie uns in einem kostenlosen Erstgespräch über Ihre Anforderungen sprechen.

Jetzt Kontakt aufnehmen

App-Schnittstellen: SSO, CRM und API-Strategie für Business-Apps

Teilen

Inhaltsverzeichnis

Carola Schulte, App-Entwicklerin

TL;DR - Die Essenz

Warum Integration Pflicht ist (keine Insellösung)

Das Datensilos-Problem

SSO (Single Sign-On): Ein Login für alles

SSO-Protokolle im Vergleich

OAuth 2.0: Der Standard für Cloud-Apps

SAML 2.0: Enterprise-Standard

LDAP: On-Premise Active Directory

CRM-Integration: Salesforce, HubSpot, Custom

Salesforce-Integration (REST API)

HubSpot-Integration (REST API)

Custom-CRM-Integration (Legacy-Systeme)

ERP-Integration: SAP, Microsoft Dynamics, DATEV

API-Strategien: REST vs. GraphQL vs. WebSockets

REST API: Der Standard

GraphQL: Flexibler, aber komplexer

WebSockets: Realtime-Kommunikation

Real Cases: Integration in der Praxis

Case 1: Wächterkontrollsystem (CRM-Sync)

Case 2: Inventur-Scanner (ERP-Export)

Case 3: Mensa-NFC-App (LDAP-SSO + Studenten-DB)

Kosten-Übersicht: Was kostet Integration wirklich?

Integrations-Kosten nach Komplexität

Security: OAuth-Tokens, API-Keys, TLS-Pinning

API-Keys: Einfach, aber unsicher

OAuth 2.0 Tokens: Best Practice

TLS-Pinning: Schutz vor Man-in-the-Middle

Häufige Integrations-Fehler

Fehler 1: Hardcoded Credentials

Fehler 2: Keine Retry-Logic

Fehler 3: Keine Timeout-Limits

Fehler 4: Keine Pagination bei großen Datensets

Checkliste: Integrations-Strategie definieren

Vor Projektstart

Tech-Entscheidungen

Security

Nach Integration

Fazit: Integration ist Pflicht, aber planbar

Lassen Sie uns über Ihre Integrations-Strategie sprechen

Verwandte Themen

Ihr App-Projekt besprechen?

Weitere interessante Artikel

App an ERP & Altsysteme anbinden: SAP, DATEV, Warenwirtschaft

App-Login: Biometrie, Passkeys, sichere Speicherung

Business-App-Entwicklung: B2B-Apps für Unternehmen