Authentifizierung vs. Autorisierung: Was ist der Unterschied?

Authentifizierung ist die Prüfung, wer Sie sind; Autorisierung ist die Entscheidung pro Anfrage, was Sie dürfen. Jedes sichere System braucht beides. Das Hotel macht es greifbar: Ihr Ausweis an der Rezeption ist Authentifizierung; die Schlüsselkarte, die Zimmer 412 öffnet – und nur Zimmer 412 –, ist Autorisierung. Es sind verschiedene Fragen, zu verschiedenen Zeitpunkten gestellt, von verschiedenen Mechanismen beantwortet, und sie scheitern auf verschiedene Weise – deshalb liefern Systeme, die beides vermischen, am Ende beide Arten von Sicherheitslücken aus.

Das Wichtigste in Kürze

Wie Authentifizierung und Autorisierung bei einer Anfrage ablaufen

1  POST /login  (Zugangsdaten + MFA)         ── AUTHENTIFIZIERUNG, einmalig
   ← Session-Token / Cookie: Identität hergestellt

2  GET /documents/xKd91m                     ── jede weitere Anfrage:
   a · Token validiert        → Identität wiederhergestellt       (Authn-Mechanik)
   b · Berechtigung geprüft   → darf ADA DIESES Dokument lesen?   (Authz-Entscheidung)

   → 200  beide Prüfungen bestanden
   → 401  kein/ungültiges Token – WWW-Authenticate-Challenge; Anmeldung behebt es
   → 403  Token gültig, Berechtigung verweigert – erneute Anmeldung ändert nichts
   → 404  manche APIs verbergen verbotene Objekte ganz (RFC 9110 erlaubt das)

Dieselbe Trennung im Anwendungscode – einmal anmelden, bei jeder Operation neu geprüft werden:

// JavaScript / Node.js — Back4app JS SDK
// Authentication: once — who are you?
const user = await Parse.User.logIn('ada', password); // session token issued

// Authorization: every request — may YOU do THIS?
const doc = await new Parse.Query('Document').get('xKd91m');
// found if an ACL entry grants ada read · "not found" if not

doc.set('title', 'Renamed');
await doc.save(); // succeeds only if an entry grants ada WRITE

// Flutter / Dart — Back4app Flutter SDK
// Authentication: once — who are you?
final user = ParseUser('ada', password, null);
await user.login(); // session token issued

// Authorization: every request — may YOU do THIS?
final response = await QueryBuilder<ParseObject>(ParseObject('Document'))
    .query(); // returns only rows whose ACLs grant ada read

final doc = response.results!.first as ParseObject;
doc.set('title', 'Renamed');
await doc.save(); // succeeds only if an entry grants ada WRITE

// iOS / Swift — Back4app Swift SDK
// Authentication: once — who are you?
let user = try await User.login(username: "ada", password: password)
// session token issued

// Authorization: every request — may YOU do THIS?
guard var doc = try await Document.query("objectId" == "xKd91m").first()
else { return } // found only if an ACL entry grants ada read

doc.title = "Renamed"
_ = try await doc.save() // succeeds only if an entry grants ada WRITE

// Android / Kotlin — Back4app Android SDK
// Authentication: once — who are you?
val user = ParseUser.logIn("ada", password) // session token issued

// Authorization: every request — may YOU do THIS?
val doc = ParseQuery.getQuery<ParseObject>("Document").get("xKd91m")
// found if an ACL entry grants ada read · "not found" if not

doc.put("title", "Renamed")
doc.save() // succeeds only if an entry grants ada WRITE

Authentifizierung vs. Autorisierung im direkten Vergleich

Zwei Zeilen verdienen eine Fußnote. Wo sie läuft: Authentifizierung konzentriert sich naturgemäß am Rand – ein Anmeldeablauf, ein Identity Provider –, während Autorisierung neben die Daten gehört, die sie schützt, denn “darf dieser Nutzer dieses Objekt anfassen” braucht das Objekt. Scheitert als: Die Bedrohungsmodelle sind disjunkt – Credential Stuffing und Phishing greifen die Authentifizierung an (weshalb MFA die wirksamste Authn-Abwehr ist), während Broken Object Level Authorization als typischer Authz-Fehler die API-Sicherheitslisten anführt: angemeldeter Nutzer, falsches Objekt, niemand hat geprüft.

401 und 403, genau betrachtet

Die Statuscodes sind die Unterscheidung in Zahlenform, und RFC 9110 ist dabei präzise. 401 Unauthorized ist die langlebigste Fehlbenennung der Webgeschichte: Gemeint ist nicht authentifiziert – der Anfrage fehlen “gültige Authentifizierungsdaten”, die Antwort muss eine WWW-Authenticate-Challenge enthalten, und das Vorlegen von Zugangsdaten kann das Problem lösen. 403 Forbidden bedeutet, dass der Server genau verstanden hat, wer fragt, und trotzdem ablehnt – eine erneute Authentifizierung ist per Definition zwecklos. Und die Spezifikation erlaubt einen dritten Zug, den Sicherheitsteams schätzen: 404 statt 403 zu antworten, damit eine verbotene Ressource nicht ihre eigene Existenz bestätigt. Die richtigen Codes sind keine Pedanterie; Clients bauen ihre Retry- und Neuanmeldelogik darauf auf, und ein 403, das eigentlich ein 401 sein müsste, schickt Nutzer gegen eine Wand statt zu einem Anmeldeformular.

OAuth, OIDC und die ewige Verwechslung

Die Verwechslung hat eine Antwort, die in der Spezifikation steht. Der Titel von OAuth 2.0 lautet “The OAuth 2.0 Authorization Framework” – es überträgt Berechtigungen mit begrenztem Scope, und die OpenID-Connect-Spezifikation existiert genau deshalb, weil OAuth allein keine Auskunft darüber geben kann, wie sich ein Endnutzer authentifiziert hat. OIDC ergänzt die Identitätsschicht: ein ID Token, das bestätigt, wer sich authentifiziert hat, getrennt vom Access Token, das festhält, was der Inhaber darf. Jeder “Anmelden mit …”-Button ist OIDC, das Authentifizierung über die Autorisierungsmechanik von OAuth abwickelt – ein Ablauf, beide Konzepte, sauber geschichtet statt vermischt.

Die drei Fehler, die in Produktion landen

Autorisierung im Client. Den Löschen-Button auszublenden ist Oberflächengestaltung; dass der Server entscheidet, ob das Löschen ausgeführt wird, ist Sicherheit. Laut OWASP gilt: standardmäßig verweigern, serverseitig durchsetzen und Client-Prüfungen nur als UX-Hinweise behandeln. Angemeldet ≠ berechtigt. Die Authentifizierung zu prüfen, aber nicht den Besitz des Objekts – /documents/42 wird an jede gültige Session ausgeliefert –, ist Broken Object Level Authorization, die häufigste Klasse von API-Schwachstellen. Die Prüfung erfolgt pro Objekt, pro Anfrage, ohne Ausnahme. Reihenfolge der Middleware. Erst authentifizieren, dann autorisieren, im Code wie im Konzept: Die Identitäts-Middleware stellt fest, wer fragt, danach fragen die Handler, ob er darf – und eine Autorisierungsprüfung, die läuft, bevor die Identität feststeht, autorisiert stillschweigend anonyme Nutzer.

Typische Anwendungsfälle

• App-Anmeldung + Datenberechtigungen – die alltägliche Kombination: ein Anmeldeablauf, danach Regeln pro Objekt für alles Weitere.
• API-Design – 401/403-Semantik, Tokens mit begrenztem Scope und Prüfungen auf Objektebene als Fehlersprache des Vertrags.
• Multi-Tenant-SaaS – Authentifizierung über alle Tenants hinweg geteilt; Autorisierung innerhalb jedes Tenants strikt abgegrenzt.
• Admin- und Support-Werkzeuge – Step-up-Authentifizierung und erweiterte Autorisierung als bewusst getrennte Ereignisse.
• Öffentliche + private Inhalte – anonymes Lesen als Autorisierungsregel, der Beweis, dass beide Konzepte unabhängig voneinander laufen.

Welche Prüfung fehlt Ihnen? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Die Trennung ist konzeptionell, nicht immer architektonisch. Kleine Apps führen beides zu Recht im selben Middleware-Stack aus; die Disziplin besteht darin, die Prüfungen getrennt zu halten, nicht die Server.
• Starke Authentifizierung rettet keine schwache Autorisierung. Passkeys und MFA verifizieren die Identität tadellos – für ein System, das danach jeden alles lesen lässt. Die Fehler sind voneinander unabhängig.
• Autorisierung pro Anfrage hat ihren Preis. Entscheidungen cachen, Regeln in die Datenschicht verlagern und Berechtigungen indizieren – so bleibt “alles prüfen” schnell.
• Step-up verwischt die Zeitachse. Sensible Aktionen verlangen mitten in der Session eine erneute Authentifizierung – Authentifizierung geschieht also nicht strikt “einmal”, sondern “einmal pro Vertrauensstufe”.
• Unscharfe Begriffe erzeugen echte Bugs. Teams, die für beide Hälften “Auth” sagen, schreiben Tickets, Tests und Fehlercodes, die beides vermengen; die Wörter sind die billigste Verteidigung.

Authentifizierung und Autorisierung 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 Architektur der Plattform ist die Trennung: Die Klasse User, Sessions, Social Login und der MFA-Adapter beantworten, wer Sie sind, und erzeugen ein widerrufbares Session-Token – danach beantworten ACLs, Berechtigungen auf Klassenebene und Rollen, was Sie dürfen, serverseitig ausgewertet bei jeder REST-, GraphQL- und Live-Query-Anfrage, genau wie die Code-Tabs zeigen: einmal anmelden, bei jeder Operation neu geprüft werden. Der Abschnitt über Fehler wird damit zur Strukturfrage: Autorisierung kann nicht clientseitig stattfinden, weil Back4app sie hinter der API durchsetzt, nicht autorisierte Objekte kommen als “nicht gefunden” zurück, statt ihre Existenz zu bestätigen, und “standardmäßig verweigern” ist ein einziges Häkchen an einer Klasse. Die beiden Fragen bleiben getrennt, weil die Plattform sie nie verschmelzen lässt.