Die Authentifizierung überprüft die Identität von Benutzenden (bzw. in Machine-to-Machine-Szenarien, eines Clients oder Services), bevor diese auf eine geschützte Ressource zugreifen können. Sie beantwortet die grundlegende Frage: „Wer sind Sie?“

Bevor eine Anwendung Zugriff gewährt, muss sie bestätigen, dass die anfragende Entität tatsächlich diejenige ist, für die sie sich ausgibt. Die Authentifizierung ist der erste Schritt der Zugriffskontrolle und geht immer der Autorisierung voraus. Sie müssen eine Identität verifizieren, bevor Sie bestimmen, worauf diese Identität zugreifen darf.

Benutzende und Services beweisen ihre Identität, indem sie Anmeldedaten oder Verifizierungsfaktoren übermitteln, die das System anhand von gespeicherten Datensätzen oder einem vertrauenswürdigen externen Identity-Anbieter validiert. Stellen Sie sich das so vor, als würde ein Entwickler oder eine Entwicklerin einem Remote-Server einen SSH-Schlüssel (Secure Shell) präsentieren: Der Server überprüft die Signatur des Schlüssels, um die Identität des Clients zu bestätigen.

Warum das wichtig ist: Die Authentifizierung stellt die Identität fest, bevor der Zugriff gewährt wird. Ohne eine verifizierte Identität kann Ihre Anwendung keine Autorisierungsrichtlinien durchsetzen, sensible Daten nicht schützen und keine Audit-Trails erstellen.

Authentifizierungsfaktoren werden in drei verschiedene Kategorien eingeteilt. Die inhärente Sicherheitsstärke der Multi-Faktor-Authentifizierung (MFA) ergibt sich aus der Kombination von Faktoren aus zwei oder mehr verschiedenen Kategorien.

Faktorkategorie	Nachweismechanismus	Typisches Beispiel
Wissen (Etwas, das man weiß)	Ein vom Benutzenden auswendig gelerntes Geheimnis	Passwort, persönliche Identifikationsnummer (PIN), Passphrase
Besitz (Etwas, das man hat)	Ein physisches Gerät oder Token unter der Kontrolle der Benutzenden	Smartphone (für TOTP/Push), Hardware-Sicherheitsschlüssel, FIDO2/WebAuthn-Schlüssel, Smartcard
Inhärenz (Etwas, das man ist)	Ein einzigartiges, verifizierbares biologisches Merkmal	Fingerabdruck, Gesichtserkennung, Iris-Scan

Neben den Passwörtern gibt es mehrere Authentifizierungsverfahren, die jeweils Kompromisse in Bezug auf Sicherheit und Benutzerfreundlichkeit erfordern.

Passwort-Authentifizierung

Die passwortbasierte Authentifizierung ist die gängigste Methode. Benutzende geben Anmeldedaten ein, die mit sicher gespeicherten Datensätzen abgeglichen werden.

Die sichere Passwortspeicherung erfordert adaptive, rechenintensive Hashing-Algorithmen wie Argon2, bcrypt oder PBKDF2, stets mit eindeutigen Salts für jedes Passwort (NIST SP 800-63B). Verwenden Sie niemals veraltete Algorithmen wie MD5 oder SHA-1.

Schwachstellen bei Passwörtern:

• Phishing und Malware stehlen Passwörter direkt
• Wiederverwendung von Passwörtern auf mehreren Websites ermöglicht die Kompromittierung mehrerer Accounts nach einer Sicherheitsverletzung
• Schwache Passwörter, die Benutzende wählen, weil sie leicht zu merken sind
• Credential Stuffing verwendet kompromittierte Passwortlisten aus früheren Sicherheitslücken

Reine Passwort-Authentifizierung reicht für Produktionssysteme nicht aus.

Multi-Faktor-Authentifizierung

Bei MFA müssen Benutzende ihre Identität anhand von zwei oder mehr unterschiedlichen Faktoren aus verschiedenen Kategorien verifizieren, bevor der Zugriff gewährt wird.

Nach der Eingabe eines Passworts müssen Benutzende einen zweiten Faktor angeben, z. B. einen Code aus einer Authentifikator-App, eine Bestätigung per Push-Benachrichtigung oder einen biometrischen Scan. Das blockiert Diebstähle von Anmeldedaten, weil Angreifer beide Faktoren benötigen. SMS- und E-Mail-Codes sind schwächer als Push-Benachrichtigungen oder FIDO2-Hardware-Authentifikatoren.

Passkeys (FIDO2/WebAuthn)

Passkeys ersetzen Passwörter durch FIDO2-Anmeldedaten, die von Natur aus Phishing-resistent sind. Sie basieren auf dem FIDO2-Protokoll (WebAuthn und CTAP).

Passkeys verwenden Public-Key-Kryptographie: Während der Registrierung generiert das Gerät ein öffentliches/privates Schlüsselpaar. Der private Schlüssel ist kryptografisch an das Gerät gebunden und so konzipiert, dass er nicht aus der sicheren Enklave des Geräts exportiert werden kann. Der öffentliche Schlüssel registriert sich beim Service und beweist die Echtheit des Geräts.

Beim Anmelden signiert das Gerät eine kryptografische Abfrage. Diese Signatur funktioniert nur für die spezifische Domain, die sie angefordert hat. Eine Phishing-Website kann die Signatur nicht abfangen und wiederverwenden, auch nicht mit Echtzeit-Phishing-Proxys. Passkeys bieten Phishing-resistente Sicherheit auf MFA-Niveau, da der private Schlüssel das Gerät niemals verlässt und über Biometrie oder eine Geräte-PIN entsperrt wird. Sie können geräteübergreifend über Plattform-Anmeldedaten-Manager (z. B. iCloud-Schlüsselbund) synchronisiert werden, sofern die Richtlinien nicht vorschreiben, dass sie an das Gerät gebunden bleiben.

Föderiertes Identity-Management und Social Login

Beim föderierten Identity-Management wird die Authentifizierung an einen vertrauenswürdigen externen Identity-Anbieter delegiert.

OpenID Connect (OIDC): Benutzende authentifizieren sich beim Identity-Anbieter. Die Anwendung erhält ein kryptografisch signiertes ID-Token, das verifizierte Identity-Claims (E-Mail-Adresse, Name) enthält, ohne die Anmeldedaten der Benutzenden zu verarbeiten.

Dadurch entfällt die Notwendigkeit, Anmeldedaten zu speichern, der Aufwand beim Onboarding wird reduziert und die Anwendung kann die Sicherheitsinfrastruktur des Identity-Anbieters nutzen. In Unternehmensumgebungen ist SAML 2.0 auch für Single Sign-On (SSO) üblich.

Single Sign-On

SSO ermöglicht es Benutzenden, sich einmal bei einem zentralen Identity-Anbieter zu authentifizieren und anschließend Zugriff auf mehrere Anwendungen zu erhalten, ohne die Anmeldedaten erneut eingeben zu müssen.

SSO verwendet Protokolle wie SAML 2.0 oder OpenID Connect. Der Identity-Anbieter stellt ein Sicherheitstoken aus, nachdem sich die Benutzenden angemeldet haben, und hält die Session aufrecht. Apps vertrauen dieser Session für den Zugriff, ohne dass neue Logins erforderlich sind. Viele Unternehmen richten die Lebensdauer von SSO-Sessions nach typischen Arbeitszeitmustern aus. Die tatsächliche Dauer hängt jedoch von Sicherheitsrichtlinien, Risikoindikatoren und Absicherungsanforderungen ab.

Moderne Authentifizierung verwendet einen dedizierten Autorisierungsserver oder Identity-Anbieter, der standardbasierte Token für den Zugriff ausstellt.

OpenID Connect (OIDC) und OAuth 2.0

Der Unterschied im Überblick:

OAuth 2.0 ist ein Autorisierungs-Framework, das ausschließlich für die Zugriffsdelegierung entwickelt wurde. Es fehlt ein standardisiertes Token oder Protokoll zur Überprüfung der Identität von Endbenutzenden.

OpenID Connect (OIDC) ist eine Identity-Ebene, die auf OAuth 2.0 aufbaut. OIDC bietet Clients eine standardisierte Methode zur Überprüfung der Benutzeridentität mithilfe eines ID-Tokens, das signierte Authentifizierungs-Claims des Identity-Anbieters enthält.

Sie arbeiten zusammen: OIDC übernimmt die Authentifizierung (Identitätsnachweis) und OAuth 2.0 die Autorisierung (Gewährung des API-Zugriffs).

Der Autorisierungscode-Ablauf mit PKCE

Der Autorisierungscode-Ablauf mit PKCE (Proof Key for Code Exchange) ist der empfohlene Ablauf für Web- und Mobilanwendungen. PKCE verhindert Angriffe, bei denen Autorisierungscodes abgefangen werden.

Funktionsweise: Die App generiert einen Code-Verifier mit hoher Entropie und eine Hash-Code-Abfrage. Die Benutzenden authentifizieren sich beim Autorisierungsserver. Der Server gibt einen kurzlebigen Autorisierungscode aus (der innerhalb weniger Minuten abläuft). Der Server überprüft, ob der Verifier der Abfrage entspricht, bevor er Token ausgibt.

Der Server stellt ein ID-Token aus, das Authentifizierungs-Claims für den Client enthält, und ein Access Token für das Aufrufen von APIs. Wenn die Anwendung Offline-Zugriff anfordert (über den offline_access-Bereich), gibt der Server ein Refresh Token aus, das verwendet werden kann, um Access Token ohne erneute Authentifizierung zu erneuern.

Token-basierte Authentifizierung und JWTs

APIs authentifizieren nicht die Benutzenden direkt, sondern überprüfen die Token. Dieser Ansatz macht die Authentifizierung neutral und skalierbar, da die API keine Session-Informationen in einer Datenbank speichern muss.

JSON Web Token (JWTs) sind das gängigste Token-Format. Sie ermöglichen eine neutrale API-Validierung, da alle erforderlichen Claims im Token enthalten sind. Einige Architekturen bleiben vollständig neutral, während andere je nach Sicherheitsanforderungen optional zusätzliche Prüfungen durchführen (z. B. Benutzerstatus oder Token-Widerruf).

Wenn ein Client die API aufruft, ist das Access Token im Header Authorization: Bearer <token> enthalten. Die API muss das JWT bei jeder Anfrage validieren, um sicherzustellen, dass es authentisch, nicht abgelaufen und für die Anwendung bestimmt ist:

• Stellen Sie sicher, dass die Token-Struktur dem JWT-Format „header.payload.signature“ entspricht.
• Überprüfen Sie die Signaturintegrität mit dem entsprechenden Schlüssel, um sicherzustellen, dass das Token nicht manipuliert wurde.
• Überprüfen Sie die Claims exp (expiration), optional nbf (not before) und iat (issued at), um ungültige oder verfrühte Token abzulehnen.
• Überprüfen Sie den Aussteller iss (issuer) und stellen Sie sicher, dass er mit Ihrem vertrauenswürdigen Identity-Anbieter übereinstimmt.
• Verifizieren Sie die Zielgruppe aud (audience) und stellen Sie sicher, dass sie mit Ihrer Anwendung übereinstimmt.
• Bevorzugen Sie asymmetrische Signaturalgorithmen (RS256 oder ES256), sodass die API-Token mit einem öffentlichen Schlüssel validiert werden, ohne gemeinsame Secrets speichern zu müssen. Verwenden Sie HS256 nur in vollständig vertrauenswürdigen Umgebungen.
• Akzeptieren Sie niemals den Algorithmus none (Keine), da dieser die Signaturprüfung umgeht.

APIs, Services und Machine-to-Machine-Kommunikation erfordern eine kryptografische Identity-Prüfung, die nicht auf menschlicher Interaktion beruht.

Client-Anmeldedaten-Flow: Der OAuth 2.0-Flow für die Server-zu-Server-Kommunikation. Der Service authentifiziert sich mit client_id und client_secret (die als vertrauliche Anmeldedaten geschützt werden müssen und niemals der Versionskontrolle unterliegen). Nach der Validierung der Anmeldedaten stellt der Autorisierungsserver ein Access Token aus.

Asymmetrische Schlüsselpaare: Services können asymmetrische Schlüsselpaare verwenden, um Clients durch eine signierte JWT-Assertion (RFC 7523) zu authentifizieren. Der Autorisierungsserver validiert die Signatur mit dem registrierten öffentlichen Schlüssel, ohne sich auf Shared Secrets zu verlassen.

Workload Identity: Cloud-Platformen bürgen kryptografisch für ausgeführte Services und stellen dynamisch sehr kurzlebige Anmeldedaten aus. Dadurch werden langlebige statische Secrets beseitigt.

Das Erstellen sicherer Anwendungen erfordert die Befolgung moderner Best Practices für Identity-Management.

Sicherheitsaspekt	Empfehlung für Entwicklungsteams
Phishing-Schutz	Geben Sie FIDO2/WebAuthn-Passkeys Vorrang vor allen anderen Faktoren (einschließlich SMS und TOTP), um den stärksten Schutz vor Anmeldedaten-Diebstahl zu bieten.
Flow-Sicherheit	Implementieren Sie den Autorisierungscode-Ablauf mit PKCE für alle Clients.
Token-Lebensdauer	Verwenden Sie kurzlebige Access Token (z. B. 15–60 Minuten), um das Angriffsfenster im Falle eines Diebstahls zu minimieren. Verwenden Sie Refresh-Token-Rotation für eine reibungslose Erneuerung.
Token-Speicherung	Vermeiden Sie die Speicherung sensibler Token (Access oder Refresh) in localStorage oder sessionStorage, da Cross-Site-Scripting-(XSS)-Risiken bestehen. Setzen Sie für Browser-Apps bevorzugt auf sichere HttpOnly-Cookies für SPAs und speichern Sie Token nur im Arbeitsspeicher, nicht in localStorage oder sessionStorage. Herkömmliche Web-Apps sollten serverseitige Sessions mit sicheren HttpOnly-Cookies verwenden.
API-Token-Validierung	Validieren Sie die JWT-Signatur bei jeder geschützten API-Anfrage. Das Auslassen dieser Überprüfung stellt eine kritische Sicherheitsschwachstelle dar.
Schutz von Anmeldedaten	Setzen Sie auf sichere Passwörter mit adaptivem Hashing (Argon2 oder bcrypt) und implementieren Sie Anzahlbegrenzungen, um Brute-Force- und Credential-Stuffing-Angriffe abzuwehren. Verwenden Sie Funktionen zur Erkennung kompromittierter Passwörter, um bekannte kompromittierte Anmeldedaten automatisch zu kennzeichnen.

Was ist der Unterschied zwischen Authentifizierung und Autorisierung?

Die Authentifizierung bestätigt die Identität: „Wer sind Sie?“ Die Autorisierung legt den Zugriff fest: „Was können Sie tun?“ Die Authentifizierung erfolgt vor der Autorisierung, d. h. Sie müssen Ihre Identität nachweisen, bevor das System Ihre Berechtigungen überprüft.

Warum ist die reine Passwort-Authentifizierung nicht mehr sicher?

Passwörter sind sehr anfällig für Phishing- und Credential-Stuffing-Angriffe und daher die größte Sicherheitslücke. Moderne Sicherheit erfordert die Implementierung von MFA oder die Umstellung auf Phishing-resistente, passwortlose Methoden wie Passkeys.

Was ist die heute sicherste Authentifizierungsmethode?

FIDO2/WebAuthn-Passkeys sind derzeit am sichersten. Sie verwenden Public-Key-Verschlüsselung und sind an die Quelle gebunden. Die Anmeldedaten funktionieren nur für die spezifische Domain, sodass Angreifer sie nicht abfangen und wiederverwenden können.

Welche Rolle spielt OpenID Connect (OIDC) bei der Authentifizierung?

OIDC erweitert OAuth 2.0 durch eine Identitätsprüfung. Dabei wird das ID-Token hinzugefügt, wobei es sich um ein JSON-Web-Token (JWT) handelt, das einen standardisierten, überprüfbaren Nachweis der Benutzeridentität bietet. OAuth 2.0 allein kann das nicht leisten.

Was ist das primäre Sicherheitsrisiko eines gestohlenen JWT Access Tokens?

Mithilfe eines gestohlenen Access Token können Angreifende sich als Benutzende ausgeben, bis das Token abläuft. Da JWTs neutral sind und es schwierig ist, sie sofort zu widerrufen, sollten Sie sehr kurzlebige Access Token (15–60 Minuten) verwenden und Refresh-Token-Rotation implementieren, um den Schaden zu begrenzen. Durch Rotation lässt sich der Diebstahl sofort erkennen, weil der Server das vorherige Token nach jeder Verwendung ungültig macht.

Wie funktioniert die passwortlose Authentifizierung?

Die passwortlose Authentifizierung macht das Auswendiglernen von Secrets überflüssig. Stattdessen stützt sie sich auf den Besitz (z. B. einen gerätegebundenen Passkey oder Hardwareschlüssel) oder auf Inhärenzfaktoren (z. B. Biometrie), um die Identität von Benutzenden sicher zu verifizieren.

Die Authentifizierung ist zentral für die Anwendungssicherheit, aber sie ist nur der erste Schritt. Damit Ihr Sicherheitsmodell vollständig ist, müssen Sie verstehen, wie der Zugriff kontrolliert wird, nachdem die Identität bestätigt wurde. 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.