Was ist Identitäts- und Zugriffsverwaltung (IAM)?

IAM ist ein Framework aus Richtlinien und Technologien, das den richtigen Benutzern zur richtigen Zeit den richtigen Zugriff auf die richtigen Ressourcen gibt. Identitäts- und Zugriffsverwaltung ist die Disziplin hinter jedem Anmeldefenster und jeder Berechtigungsprüfung – und eine Klarstellung vorweg: Große Cloud-Anbieter verkaufen zusätzlich Produkte namens “IAM”, mit denen sich der Zugriff auf ihre eigene Infrastruktur steuern lässt; das sind Umsetzungen dieser Disziplin, nicht ihre Definition. Dieser Artikel behandelt die Disziplin – einschließlich der Variante, die jeder App-Entwickler baut oder erbt, meist ohne sie IAM zu nennen.

Das Wichtigste in Kürze

Der Identitätslebenszyklus: Eintritt, Wechsel, Austritt

Das Tagesgeschäft von IAM ist eine Schleife, die jedes Konto durchläuft, und sie lässt sich in konkrete Operationen übersetzen:

EINTRITT Identität anlegen → E-Mail verifizieren → Zugangsdaten/Session ausgeben
         (Provisionierung — bei Mitarbeitenden via SCIM automatisiert)
WECHSEL  Rollenwechsel · Teamwechsel · Erteilen und Widerrufen von Rechten
         (Autorisierung folgt den Rollen: ein Wechsel ist ein Datenupdate)
AUSTRITT Sessions SOFORT widerrufen → Konto deaktivieren → löschen oder anonymisieren
         (Deprovisionierung — übersprungene Schritte werden zu "verwaisten Konten",
          dem Prüfungsbefund, der in Breach-Reports immer wieder auftaucht)

Dieselbe Schleife als API-Aufrufe:

// JavaScript / Node.js — Back4app JS SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret, email: '[email protected]' });

// Move: authorization follows roles, not people
editors.getUsers().add(user);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// Flutter / Dart — Back4app Flutter SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
final user = ParseUser('ada', secret, '[email protected]');
await user.signUp();

// Move: authorization follows roles, not people
editors.addRelation('users', [user]);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// iOS / Swift — Back4app Swift SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
var user = User()
user.username = "ada"
user.password = secret
user.email = "[email protected]"
let signedUp = try await user.signup()

// Move: authorization follows roles, not people
try await editors.users.add([signedUp]).save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// Android / Kotlin — Back4app Android SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.email = "[email protected]"
user.signUp()

// Move: authorization follows roles, not people
editors.users.add(user)
editors.save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

Authentifizierung vs. Autorisierung

Die Unterscheidung, auf der die ganze Disziplin ruht:

Die Flughafen-Version, einmal: Passkontrolle gegenüber Bordkarte. Dann die Engineering-Version, die mehr zählt: Die Authentifizierung erzeugt die Identität, die eine Session trägt; die Autorisierung verbraucht sie bei jeder folgenden Anfrage – deshalb versagen beide unterschiedlich und werden getrennt gehärtet.

Die vier Säulen – und die drei Buchstaben des Marktes

Die funktionale Anatomie: Authentifizierung (Identität nachweisen – Passwörter, MFA, SSO, passwortlos), Autorisierung (Aktionen entscheiden – Rollen, Berechtigungen, Objektregeln), Lebenszyklus (die Schleife aus Eintritt, Wechsel, Austritt) und Audit (die chronisch unterschätzte vierte Säule: Protokolle, Zugriffsüberprüfungen und die Fähigkeit, “Wer konnte das lesen, und wer hat es getan?” zu beantworten). Der Anbietermarkt zerlegt dasselbe Gebiet in Segmente, denen Sie im Einkauf begegnen: AM (Access Management – Anmeldung, SSO, MFA), IGA (Governance – Zertifizierungen, Funktionstrennung, die Schicht “Sollten sie das haben?” über dem operativen “Können sie es?”) und PAM (Privileged Access – Tresorhaltung und bedarfsgerechte Rechteerhöhung für die Konten, deren Kompromittierung das Ende bedeutet). Dieselbe Disziplin, zwei Karten.

Der Standard-Stack

Der Buchstabensalat, aufgelöst in Aufgaben – die Tabelle, die die bestplatzierten Seiten nie liefern:

Workforce-IAM vs. CIAM

Die Unterscheidung verdient ihre Tabelle, weil die üblichen Inhalte fast ausschließlich über die linke Spalte geschrieben sind, während die meisten Entwickler, die ein Glossar lesen, an der rechten bauen: Registrierungsabläufe, Session-Behandlung und Kontowiederherstellung für die Benutzer einer App sind CIAM – die Disziplin gilt auch dann, wenn niemand im Raum das Kürzel benutzt.

Typische Anwendungsfälle

• Benutzerverwaltung in der App – Registrierung, Verifizierung, Sessions, Rollen, Löschung: CIAM als tägliche Backend-Arbeit.
• Unternehmens-SSO – ein IdP, viele Apps; MFA und Offboarding an einem einzigen Punkt durchgesetzt.
• API- und Dienstidentität – Maschinen-Zugangsdaten, Tokens mit Scope und Rotation für nicht-menschliche Aufrufer.
• Compliance-Programme – Zugriffsüberprüfungen, Audit-Spuren und Nachweise geringster Rechte für DSGVO, HIPAA, SOC 2.
• Zero-Trust-Architekturen – Identitätsprüfung pro Anfrage statt Netzwerkstandort als Vertrauenssignal.

Sollten Sie IAM bauen oder kaufen? Entscheidungsmatrix

Grenzen und Trade-offs

• IAM ist ein Prozess im Software-Gewand. Werkzeuge automatisieren Richtlinien; erfinden können sie sie nicht – Rollenentwurf, Prüfrhythmus und Offboarding-Disziplin bleiben menschliche Arbeit.
• Zentralisierung bündelt Risiko. Ein IdP heißt: eine Stelle, die abgesichert werden muss, und ein Ausfall, der alle abmeldet; Verfügbarkeits- und Wiederherstellungsplanung gehören zur Bequemlichkeit dazu.
• Föderation erbt Vertrauen. Jede App, die einem IdP vertraut, erbt dessen Kompromittierungen; Token-Validierung und kurze Laufzeiten sind die Eindämmung.
• Lebenszyklus-Automatisierung braucht Wahrheit. Provisionierung ist nur so gut wie das führende System, das sie speist; veraltete HR-Daten werden zu veralteten Zugriffen.
• Audit ohne Prüfung ist Theater. Protokolle, die niemand liest, und Zertifizierungen, auf die niemand reagiert, befriedigen Checklisten, keine Angreifer.

IAM mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Entwicklersicht auf IAM ist genau das, was mitgeliefert wird: Die Klasse User ist der Identitätsspeicher; Registrierung, E-Mail-Verifizierung, Passwort-Reset und Social Login decken die Authentifizierung ab (mit einem MFA-Adapter für die Rechteerhöhung); widerrufbare Session Tokens tragen die Identität; Rollen und objektbezogene ACLs sind die Säule der Autorisierung, durchgesetzt bei jeder REST-, GraphQL- und Live-Query-Anfrage; und der Lebenszyklus in den Code-Tabs – Eintritt, Wechsel, Austritt – ist gewöhnliche Datenarbeit, mit Cloud-Code-Triggern als dem Ort, an dem Richtlinien durchgesetzt werden (Wegwerf-E-Mails blockieren, Audit-Ereignisse protokollieren, Deprovisionierung kaskadieren). Es ist CIAM als Plattformschicht: Die Säulen kommen zusammengesetzt an, und Ihre Arbeit verschiebt sich vom Bau der Identitätsmaschinerie hin zur Entscheidung über Richtlinien.