Authentifizierung vs. Autorisierung - was ist der Unterschied?
IAM
Identitätsmanagement
Identity und Access Management ist die Grundlage jeder sicheren Anwendung. Wer darf was tun? Wie werden Identitaeten verwaltet? Dieser Stack zeigt die Tools fuer Authentifizierung, Autorisierung und Identity Provider – von selbst gehostetem Keycloak bis hin zu managed Services wie Auth0 und Okta.
Identity und Access Management (IAM) loest zwei fundamental verschiedene Probleme: Authentifizierung (Wer bist du?) und Autorisierung (Was darfst du tun?). Beide werden oft verwechselt, benoetigen aber unterschiedliche Loesungen.
OAuth2 und OpenID Connect (OIDC) sind die modernen Standards fuer delegierte Authentifizierung. OAuth2 regelt, wie Anwendungen im Namen eines Nutzers auf Ressourcen zugreifen. OIDC baut darauf auf und liefert zusaetzlich eine verifizierte Nutzer-Identitaet (ID Token). SAML ist der aeltere Enterprise-Standard, der in vielen Unternehmens-Umgebungen noch dominiert.
Self-hosted vs. SaaS IAM: Keycloak, Authentik und Zitadel bieten volle Kontrolle, laufen in der eigenen Infrastruktur und haben keine Nutzungsabhaengigen Kosten. Auth0 und Okta sind schneller einsatzbereit, skalieren automatisch und haben erstklassige Integrationen – kosten aber bei hohem Volumen erheblich mehr.
Zugriffssteuerung: RBAC (Role-Based Access Control) weist Nutzern Rollen zu (Admin, User, Viewer). ABAC (Attribute-Based Access Control) ist feingranularer: Zugriff wird basierend auf Attributen des Nutzers, der Ressource und des Kontexts entschieden. Cerbos und Warrant implementieren diese Fine-grained-Authorization als dedizierte Services.
Haeufige Fragen & Expertenwissen
Die Unterscheidung ist fundamental und wird in der Praxis haeufig verwechselt:
Authentifizierung (AuthN) klaert: „Wer bist du?“ Sie verifiziert die Identitaet eines Nutzers oder Systems. Methoden: Passwort + Username, Multi-Faktor-Authentifizierung (MFA), Biometrie, Passkeys, Certificate-basierte Authentifizierung.
Autorisierung (AuthZ) klaert: „Was darfst du tun?“ Sie entscheidet, welche Ressourcen und Aktionen einem authentifizierten Nutzer erlaubt sind. Findet immer nach der Authentifizierung statt.
Beispiel: Ein Nutzer loggt sich ein (AuthN). Das System prueft, ob er Admin-Rechte hat und auf /admin zugreifen darf (AuthZ).
Typische Fehler:
- Autorisierung nur im Frontend pruefen – immer auch serverseitig validieren
- Kein Prinzip der geringsten Privilegien (Least Privilege) – Nutzer erhalten zu weitreichende Rechte
- Token-Validierung vergessen – immer Signatur und Ablaufzeit pruefen
OAuth2 und OIDC - wie funktionieren moderne Login-Protokolle?
OAuth2 ist ein Autorisierungs-Framework, kein Authentifizierungs-Protokoll. Es loest das Problem: „Wie kann App A auf Daten von App B zugreifen, ohne das Passwort des Nutzers zu kennen?“
Der OAuth2 Authorization Code Flow in Kuerze:
- Nutzer wird zum Identity Provider (IdP) weitergeleitet
- Nutzer authentifiziert sich beim IdP
- IdP stellt einen kurzlebigen Authorization Code aus
- App tauscht Code gegen Access Token und Refresh Token
- App nutzt Access Token fuer API-Aufrufe
OpenID Connect (OIDC) erweitert OAuth2 um einen Identity Layer: der IdP stellt zusaetzlich ein signiertes ID Token (JWT) aus, das verifizierbare Informationen ueber den Nutzer enthaelt (Name, E-Mail, Rollen). Das macht OIDC zum Standard fuer SSO.
PKCE (Proof Key for Code Exchange) ist seit 2019 Pflicht fuer alle Public Clients (SPAs, Mobile Apps) – es verhindert Code-Interception-Angriffe.
Wann Self-hosted IAM (Keycloak), wann SaaS (Auth0/Okta)?
Es gibt keine universelle Antwort – die richtige Wahl haengt von Datenschutzanforderungen, Team-Kapazitaet und Skalierungsbedarf ab.
Self-hosted (Keycloak, Authentik, Zitadel) waehlen, wenn:
- Sensible Nutzerdaten (z. B. Gesundheitsdaten, Finanzdaten) nicht die eigene Infrastruktur verlassen duerfen
- DSGVO-Konformitaet ohne DPA mit US-Anbietern benoetigt wird
- Nutzungsvolumen hoch ist und SaaS-Kosten prohibitiv werden
- Volle Anpassbarkeit (Custom Login Flows, Themes, Attribute) benoetigt wird
SaaS (Auth0, Okta) waehlen, wenn:
- Schneller Start ohne Infrastruktur-Aufwand wichtiger ist als Kontrolle
- Enterprise-SSO-Integrationen (Salesforce, Microsoft, Google Workspace) schnell benoetigt werden
- Das Team keine IAM-Expertise hat und nicht aufbauen moechte
Zitadel ist ein interessanter Mittelweg: modernes UI, aktive Entwicklung, deutlich einfacher zu betreiben als Keycloak.
Was ist Zero Trust und wie implementiere ich es?
Zero Trust ist ein Sicherheitsmodell, das davon ausgeht, dass kein Netzwerk, kein Geraet und kein Nutzer inherent vertrauenswuerdig ist – auch nicht innerhalb des eigenen Netzwerks. Der Leitsatz: „Never Trust, Always Verify.“
Die fuenf Saeulen von Zero Trust:
- Starke Identitaet: MFA fuer alle Nutzer, Certificate-basierte Service-Identitaeten
- Geraete-Validierung: Nur gemanagte, compliance-konforme Geraete erhalten Zugriff
- Least Privilege Access: Minimale Rechte, just-in-time Zugriffsgewaehrung
- Mikro-Segmentierung: Services kommunizieren nur explizit erlaubt miteinander (mTLS, Network Policies)
- Kontinuierliche Validierung: Session-Vertrauen wird kontinuierlich neu bewertet, nicht nur beim Login
Praktischer Einstieg: MFA fuer alle Admin-Zugaenge einschalten, Service Mesh mit mTLS einfuehren, API Gateway fuer alle internen API-Aufrufe als Policy Enforcement Point nutzen.
Die wichtigsten Themen im IAM-Stack ...
IAM
Identity Management
Authentifizierung
Autorisierung
OAuth2
OIDC
SSO
SAML
Keycloak
Auth0
RBAC
ABAC
Identity Provider
Zero Trust
Themenbereiche aus dem IAM-Stack
Self-hosted IAM (5)
Cloud & SaaS IAM (4)
Autorisierung & Access Control (3)
Self-hosted IAM
Identity Provider selbst betreiben - volle Kontrolle über Nutzerdaten, Single Sign-On und Protokollunterstützung (OIDC, SAML). Ideal für Teams, die Datensouveränität priorisieren und auf gehostete Dienste verzichten möchten.
Cloud & SaaS IAM
Verwaltete Identity-Dienste nehmen den Betrieb eines eigenen Identity Providers ab. Mit fertig integrierten Login-Flows, MFA und Social Login lassen sich Authentifizierungssysteme in Stunden statt Wochen integrieren.
Autorisierung & Access Control
Nach dem Login entscheidet die Autorisierungsebene, wer auf welche Ressourcen zugreifen darf. Fine-grained Authorization ermöglicht rollenbasierte und attributbasierte Zugriffssteuerung auch in komplexen Multi-Tenant-Systemen.
Genug vom IAM-Stack?
Diese Stacks könnten dich auch interessieren ...