Authentifizierung und Autorisierung sind Kernkonzepte im Identity and Access Management (IAM), die zwar beide mit Identity-Sicherheit zu tun haben, jedoch unterschieden werden müssen.

• Bei der Authentifizierung wird überprüft, wer ein Benutzer ist.
• Die Autorisierung bestimmt, was der Benutzer tun darf.

Sie melden sich bei GitHub an (Authentifizierung) und versuchen dann, das Repository einer anderen Person zu löschen. GitHub weiß, wer Sie sind, und stoppt Sie (Autorisierung).

Zuerst muss die Authentifizierung stattfinden: Sie müssen Ihre Identität nachweisen. Danach folgt die Autorisierung: Ihre Berechtigungen bestimmen, worauf Sie zugreifen können.

Die Authentifizierung beantwortet die Frage: „Wer sind Sie?“

Bevor Ihre Anwendung den Zugriff gewährt, muss sie die Identität des Benutzers überprüfen. Wenn sich ein Benutzer anmeldet, überprüfen Sie die Anmeldedaten (oder andere Faktoren), um sich zu vergewissern, dass es sich tatsächlich um die Person handelt, für die er sich ausgibt. Die Authentifizierung hat immer oberste Priorität. Die Entscheidung über den Zugriff eines Benutzers können Sie erst treffen, wenn Sie wissen, wer er ist.

Stellen Sie sich die Authentifizierung wie die Sicherheitskontrolle am Flughafen vor. Sie zeigen Ihren Ausweis vor, um Ihre Identität nachzuweisen, und der Beamte überprüft, ob Sie tatsächlich die Person sind, die im Ausweis steht.

• Passwortbasierte Authentifizierung: Benutzer geben Anmeldedaten ein, die anhand gespeicherter Datensätze validiert werden. Immer öfter reichen Passwörter alleine für moderne Sicherheitsanforderungen nicht mehr aus.
• Passkey: Benutzer authentifizieren sich mit kryptografischen Schlüsseln, die lokal durch Biometrie oder Geräte-PINs geschützt sind. Passkeys sind Phishing-resistente FIDO-Anmeldedaten und bieten eine schnellere, einfachere und sicherere Anmeldung als herkömmliche Passwörter.
• Social Login und Verbundidentität: Benutzer authentifizieren sich über externe, vertrauenswürdige Anbieter (wie Google oder GitHub) mithilfe von OpenID Connect (OIDC). Dadurch wird die Identitätsprüfung an spezialisierte Identity-Anbieter delegiert.
• Single Sign-On (SSO): Benutzer authentifizieren sich einmalig und können dann auf mehrere Anwendungen zugreifen, ohne ihre Anmeldedaten erneut eingeben zu müssen. Dies verbessert die User Experience, insbesondere in Unternehmensumgebungen.
• Multi-Faktor-Authentifizierung (MFA): Kombiniert mehrere Verifizierungsfaktoren (z. B. Wissen, Besitz, Inhärenz), um die Sicherheit zu erhöhen.

Wenn ein Benutzer Zugriff auf eine Anwendung anfordert, geschieht Folgendes:

1. Der Benutzer übermittelt Anmeldedaten an den Authentifizierungsendpoint.
2. Das System validiert die Anmeldedaten entweder lokal oder über einen Identity-Anbieter.
3. Nach erfolgreicher Validierung gibt das System ein Token aus, das die authentifizierte Identität repräsentiert.

Was ist Autorisierung?

Die Autorisierung beantwortet die Frage: „Was können Sie tun?“

Die Autorisierung legt fest, welche Aktionen authentifizierte Benutzer innerhalb eines Systems ausführen dürfen. Gängige Ansätze sind:

Methode	Beschreibung	Beispiel
Rollenbasierte Zugriffskontrolle (Role Based Access Control, RBAC)	Benutzern werden vordefinierte Rollen (Administrator, Editor, Viewer) mit festen Berechtigungen zugewiesen	Ein Benutzer mit der Rolle „Editor“ kann Dokumente bearbeiten, ein Benutzer mit der Rolle „Viewer“ kann sie nur lesen.
Attributbasierte Zugriffskontrolle (Attribute-Based Access Control, ABAC)	Zugriffsentscheidungen basierend auf dynamischen Attributen (Benutzereigenschaften, Ressourcenmetadaten, Umgebungskontext)	Finanzressourcen sind nur während der Geschäftszeiten über das Unternehmensnetzwerk zugänglich.
Beziehungsbasierte Zugriffskontrollen (ReBAC)	Autorisierung basierend auf Beziehungen zwischen Benutzern und Ressourcen	Ein Mitarbeiter kann seine eigenen Dokumente bearbeiten, nicht jedoch die privaten Entwürfe seiner Teamkollegen.

Autorisierung in der Praxis

Betrachten wir eine Projektmanagement-Anwendung:

• Die Authentifizierung bestätigt, dass der Benutzer Alex ist.
• Die Autorisierung legt fest, dass Alex (in der Rolle eines Projektmanagers) alle Projekte des Entwicklungsteams einsehen kann, jedoch keine Projekte löschen und nicht auf Abrechnungseinstellungen zugreifen darf.

Wenn Sie mit modernen Protokollen arbeiten, müssen Sie die Unterschiede zwischen Authentifizierung und Autorisierung verstehen.

Aspekt	Authentifizierung	Autorisierung
Die Frage	Wer sind Sie?	Was können Sie tun?
Der Prozess	Überprüft die Identität	Überprüft Berechtigungen
Reihenfolge	Muss zuerst stattfinden	Findet nach der Authentifizierung statt
Methoden	Passwörter, Passkeys, MFA, SSO, OIDC	RBAC, ABAC, ReBAC
Token-Typ	ID-Token (Identity-Claims)	Access Token (Berechtigungen/Scopes)
HTTP-Status	401 Unauthorized (Identitätsnachweis fehlgeschlagen)	403 Forbidden (Identität bekannt, Berechtigung verweigert)

OAuth 2.0 ist ein Autorisierungsframework – kein Authentifizierungsprotokoll.

OAuth 2.0 bietet eine standardisierte Methode, mit der eine Client-Anwendung (mit Zustimmung des Benutzers) ein Access Token von einem Autorisierungsserver erhalten kann, um auf geschützte Ressourcen zuzugreifen. Es wurde für die delegierte Autorisierung entwickelt und ermöglicht Benutzern, Drittanwendungen eingeschränkten Zugriff auf ihre Ressourcen zu gewähren, ohne ihre Passwörter dafür weiterzugeben.

OpenID Connect (OIDC)

OIDC ist ein interoperables Authentifizierungsprotokoll, das auf dem OAuth 2.0-Framework aufbaut. Es vereinfacht die Überprüfung der Benutzeridentität auf Basis der vom Autorisierungsserver durchgeführten Authentifizierung.

Es behandelt die Aspekte, die OAuth 2.0 nicht abdeckt:

• Es definiert das ID-Token: Ein standardisiertes Sicherheitstoken (kodiert als JWT) zum Nachweis, dass der Benutzer authentifiziert wurde.
• Es standardisiert Benutzeridentität-bezogenen Claims (z. B. Name und E-Mail-Adresse).

In modernen Architekturen läuft der Prozess wie folgt ab:

• OAuth 2.0 übernimmt die Autorisierung (Delegation des Zugriffs auf Ressourcen).
• OpenID Connect übernimmt die Authentifizierung (Bestätigung der Benutzer-Identity).

Normalerweise arbeiten beide Protokolle im selben Ablauf zusammen.

Moderne Anwendungen sind verteilte Systeme, die auf APIs basieren und sich zu einer primären Methode für den Zugriff auf Ressourcen entwickelt haben.

Der grundlegende Unterschied: APIs authentifizieren Benutzer nicht direkt. Sie validieren Token und setzen die API-Autorisierung durch.

Wie die Token-basierte Authentifizierung funktioniert

1. Der Benutzer authentifiziert sich bei einem Autorisierungsserver (Identity-Anbieter).
2. Der Server stellt Token aus, nachdem die Identität geprüft wurde:
   • ID-Token (Authentifizierung): Benutzeridentität-bezogene Informationen. Der Client ermittelt damit, wer sich angemeldet hat.
   • Access Token (Autorisierung): Autorisierungsinformationen (Scopes, Berechtigungen). Die API bestimmt damit, worauf der Benutzer zugreifen kann.
3. Der Client sendet API-Aufrufe mit dem Access Token im Header [Authorization: Bearer].
4. Die API validiert das Token und setzt Autorisierungsregeln auf Basis der darin enthaltenen Claims durch.

JWT-Authentifizierung verstehen

JSON Web Token (JWTs) sind das gebräuchlichste Token-Format. Sie sind in sich abgeschlossen und enthalten alle notwendigen Informationen direkt im Token.

Ein JWT besteht aus einem Header, einer Payload (Claims) und einer Signatur.

JWT-Validierung: Was die API überprüfen muss

Wenn eine API ein JWT empfängt, ist die Validierung unabdingbar. Das Auslassen einer dieser Validierungen führt zu Sicherheitslücken in der Anwendung.

Fünf wesentliche Validierungsprüfungen:

1. Token-Struktur: Überprüfen Sie zunächst, ob das Token der Struktur eines JSON Web Tokens entspricht.
2. Token-Integrität: Überprüfen Sie anhand der Signatur, ob das Token manipuliert wurde.
3. Token-Ablauf: Überprüfen Sie, ob das Token gemäß der Definition im exp-Claim abgelaufen ist.
4. Erwartete Autorität: Vergewissern Sie sich, dass das Token vom erwarteten Absender ausgestellt und signiert wurde.
   1. Vergleichen Sie es mit dem iss-Claim (Aussteller).
   2. Überprüfen Sie, ob der zum Signieren des JWT verwendete Schlüssel zur erwarteten Autorität gehört.
5. Erwartete Zielgruppe: Vergewissern Sie sich, dass das Token für Ihre Anwendung bestimmt ist und der aud-Claim mit dem Wert übereinstimmt, der Ihre Anwendung identifiziert.

JWT und undurchsichtige Token im Vergleich: Die Vor- und Nachteile

OAuth 2.0 schreibt kein bestimmtes Access Token-Format vor. Obwohl JWTs weit verbreitet sind, stellt das undurchsichtige Token eine Alternative dar – eine zufällige Zeichenfolge, die keine eingebetteten Informationen über den Benutzer oder das Token selbst enthält.

Feature	JWT-Access-Token	Undurchsichtige Access Token
Validierung	Neutral (API validiert lokal)	Nicht neutral (API muss bei jeder Anfrage den Introspektions-Endpoint des Autorisierungsservers aufrufen)
Widerruf	Vor Ablauf nur schwer möglich	Sofort möglich
Leistung	Niedrigere Latenz bei API-Anfragen (schneller)	Abfrage des Autorisierungsservers erhöht Latenz
Skalierbarkeit	Gut in verteilten Architekturen	Autorisierungsserver wird zu kritischer Bedingung

Bei beiden handelt es sich um eine gültige OAuth 2.0-Implementierung. Viele Systeme verwenden JWTs mit kurzer Ablaufzeit und Refresh Token-Rotation, um Leistung und Sicherheit in Einklang zu bringen.

Der Autorisierungscode-Ablauf mit Proof Key for Code Exchange (PKCE) ist der sicherste OAuth 2.0-Ablauf für webbasierte und mobile Anwendungen. Er demonstriert, wie Authentifizierung und Autorisierung zusammenarbeiten. Die Verwendung von PKCE schützt den Ablauf vor Abfangangriffen.

1. Benutzer initiiert die Anmeldung: Die Anwendung leitet den Benutzer mit Anforderungsdetails (Client-ID, Scopes, PKCE-Codeabfrage) an den Autorisierungsserver weiter.
2. Benutzer authentifiziert sich: Die Benutzeranmeldung erfolgt über die gehostete Anmeldeseite. Die Authentifizierung ist abgeschlossen.
3. Autorisierungscode wird ausgestellt: Der Benutzer wird mit einem kurzlebigen Autorisierungscode zurück zur Anwendung weitergeleitet.
4. Token-Austausch: Das Backend der Anwendung tauscht den Autorisierungscode gegen ein Token und sendet dazu den PKCE-Code-Verifier. Der Server stellt das ID-Token (Authentifizierung) und das Access Token (Autorisierung) aus.
5. API-Zugriff: Die Anwendung fügt das Access Token in Anfrage-Header ein, wenn geschützte APIs aufgerufen werden.
6. Token-Validierung und -Durchsetzung: Die API validiert das Access Token und setzt die Berechtigungen auf der Grundlage von dessen Claims durch, um eine ordnungsgemäße Autorisierung sicherzustellen.

Sicherheitsüberlegungen für Entwickler

Überlegung	Empfehlung
Token-Lebensdauer	Verwenden Sie kurzlebige Access Token (15–60 Minuten) und ein Refresh Token, um ein neues Access Token zu erhalten, ohne den Benutzer zur Anmeldung zu zwingen.
Least-Privilege-Prinzip	Fordern Sie die minimal erforderlichen Scopes an, die eine Anwendung benötigt, um das Risiko eines potenziellen Schadens durch kompromittierte Token zu minimieren.
Token-Validierung	Um Sicherheitsrisiken zu minimieren, sollten Token stets validiert werden.
Token-Speicherung	Speichern Sie sensible Token niemals in localStorage oder sessionStorage. Verwenden Sie sichere HttpOnly-Cookies oder einen sicheren Backend-Session-Speicher.

Um sichere Anwendungen entwickeln zu können, müssen Sie den Unterschied zwischen Authentifizierung und Autorisierung verstehen:

Begriff	Aufgabe	Protokoll/Token
Authentifizierung	Überprüfung der Identität	OpenID Connect, ID-Token
Autorisierung	Zugriffskontrolle	OAuth 2.0, Access Token

Implementierungscheckliste

• Verwendung von OpenID Connect für Benutzerauthentifizierungen
• Verwendung von OAuth 2.0 für delegierte Autorisierungen
• Serverseitige Validierung von JWTs bei jeder API-Anfrage.
• Rückgabe der Codes 401 bei Autorisierungsfehlern und 403 bei verweigerter Autorisierung
• Verwendung des Autorisierungscode-Ablaufs mit PKCE
• Sichere Speicherung der Token (HttpOnly-Cookies)
• Verwendung kurzlebiger Access Token mit Refresh Token-Rotation

Damit Sie die verschiedenen Token-Typen noch besser verstehen, erfahren Sie hier mehr über den Unterschied zwischen ID-Token und Access Token.

Die Verwendung eines Dienstes wie Auth0 kann die Implementierung der Authentifizierung und Autorisierung vereinfachen und es Entwicklern ermöglichen, sich auf ihre Kernanwendungslogik zu konzentrieren. In unserer Reihe „Einführung in IAM“ finden Sie weitere Informationen zu Identity and Access Management (IAM).

Mehr erfahren

Diese Materialien dienen nur zur allgemeinen Information. Es liegt in Ihrer Verantwortung, sich mit Blick auf Sicherheit, Datenschutz, Compliance oder geschäftliche Angelegenheiten beraten zu lassen und sich nicht ausschließlich auf die hierin bereitgestellten Informationen zu verlassen.