/
<-BACK
Security & Identity2026-06-07

Authentifizierung vs. Autorisierung: Methoden, Unterschiede und Best Practices für Entwickler

Verstehe den Unterschied zwischen Authentifizierung und Autorisierung und lerne die wichtigsten Methoden von Basic Auth bis OpenID Connect kennen.

Authentifizierung und Autorisierung: Warum du den Unterschied kennen musst

Einleitung

Wenn du Anwendungen entwickelst, kommst du früher oder später an den Punkt, an dem Nutzer auf geschützte Bereiche, Daten oder APIs zugreifen sollen. Bevor ein System jedoch entscheiden kann, was jemand darf oder nicht darf, muss zunächst geklärt werden, wer überhaupt die Anfrage stellt. Genau hier kommt die Authentifizierung ins Spiel.

In der Praxis erlebe ich immer wieder, dass Begriffe wie Authentifizierung und Autorisierung durcheinandergebracht werden. Hinzu kommen Technologien und Standards wie OAuth 2.0 oder OpenID Connect, die häufig als „Login-Lösungen“ bezeichnet werden, obwohl ihre eigentlichen Aufgaben deutlich differenzierter sind.

In diesem Artikel zeige ich dir, was Authentifizierung tatsächlich bedeutet, welche Verfahren heute am häufigsten eingesetzt werden und worin sich diese von Autorisierungs-Frameworks wie OAuth 2.0 und OpenID Connect unterscheiden. Ziel ist es, die einzelnen Konzepte klar voneinander abzugrenzen und ein solides Verständnis für moderne Identitäts- und Zugriffsverwaltung zu schaffen.

Hinweis: Der Fokus liegt ausschließlich auf Authentifizierung. Autorisierung wird kurz angerissen, weil sie den nächsten Schritt bildet, wird aber nicht im Detail behandelt.

Was ist Authentifizierung?

Authentifizierung beantwortet die grundlegende Frage „Wer bin ich?“ – – also wer versucht, auf das System zuzugreifen. Der typische Ablauf sieht so aus:

  1. Login‑Request vom Client (Browser, App, Service).
  2. Identitätsprüfung durch das Backend (Passwort, Token, Zertifikat …).
  3. Bei Erfolg: Rückgabe eines Authenticated‑Status (z. B. 200 OK); bei Misserfolg: 401 Unauthorized.

Ist die Identität geklärt, folgt später die Autorisation die definiert, was der Nutzer darf.

Übersicht der Authentifizierungsmethoden

MethodeFunktionsweiseVor‑ & NachteileTyp (Method/Framework)
Basic AuthBase64‑Kodierung von username:password im Authorization‑Header.+ Einfach; <br>– kein Schutz ohne TLS, Credentials bei jedem Request.Methode
Digest AuthMD5‑Hash‑basiertes Challenge‑Response‑Verfahren.+ Besser als Basic; <br>– veraltet, MD5‑Schwachstelle.Methode
API‑KeysZufälliger Schlüssel, bei jedem Request mit Header oder Query‑Parameter.+ Einfach zu implementieren; <br>– Leckage führt zu Missbrauch, keine eingebaute Ablaufzeit.Methode
Session‑basiertServer erzeugt Session‑ID, speichert im Speicher/DB, Cookie an Client.+ Zustandsbehaftet, gut für klassische Web‑Apps; <br>– nicht skalierbar für APIs.Methode
Bearer TokenBeliebiges Token im Header Authorization: Bearer <token>.+ Flexible, agnostisch; <br>– definiert nicht, wie Token entsteht.Muster
JWT (JSON Web Token)Signiertes JSON‑Objekt mit Claims (sub, exp, roles …).+ Stateless, selbst‑enthaltend, skalierbar; <br>– Größe, Gefahr von Schlüssel‑Lecks.Token‑Format
OAuth 2.0Autorisierungs‑Framework, gibt Access‑ und Refresh‑Token aus.+ Delegierte Zugriffsrechte, Rollen‑Based Access; <br>– kein Auth‑Mechanismus per se.Framework
OpenID ConnectSchicht über OAuth 2.0, liefert ID‑Token (JWT) zur Identitätsbestätigung.+ Kombiniert Auth & Authz; <br>– komplexe Implementierung.Framework
Single Sign‑On (SSO)Nutzer meldet sich einmal an, greift dann auf mehrere Dienste zu.+ Benutzer‑freundlich; <br>– erfordert Identitäts‑Provider (IdP).UX‑Pattern

1. Basic Authentication

Ablauf

GET /api/users HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Der Header enthält das Base64‑kodierte username:password.

Sicherheitshinweis

Base64 ist nur eine Kodierung, kein Verschlüsselungsmechanismus. Ohne HTTPS sind Anfragen leicht abzuhören. Deshalb wird Basic Auth heutzutage nur noch intern oder für automatisierte Skripte eingesetzt.

2. Digest Authentication

Digest Auth verbessert Basic, indem ein Hash‑Verfahren verwendet wird. Der Server sendet einen Nonce (ein Zufallswert), den der Client mit dem Passwort und dem Nonce hash‑t.

GET /protected HTTP/1.1
Host: example.com
Authorization: Digest username="bob",
    realm="example",
    nonce="5ccc069c403ebaf9f0171e9517f40e41",
    uri="/protected",
    response="6629fae49393a05397450978507c4ef1"

Obwohl sicherer, ist auch Digest veraltet und wird kaum noch eingesetzt.

3. API‑Keys

Ein API‑Key ist ein zufälliger String, der bei jedem Request mitgesendet wird. Beispiel:

GET /v1/orders HTTP/1.1
Host: api.example.com
X-API-Key: 7f3e9b2a-9c4d-4f0a-8c1e-2a5b9c7d6e1f

Vorteile: Einfach zu erzeugen, keine Benutzer‑Interaktion nötig. Nachteile: Leckage führt zu unautorisiertem Zugriff, kein eingebauter Ablauf.

4. Session‑basiertes Authentifizieren

Der klassische Ansatz für Web‑Apps:

  1. Nutzer loggt sich ein → Server erzeugt Session‑ID.
  2. Session‑ID wird in einem Cookie (HttpOnly, Secure) an den Client gesendet.
  3. Bei nachfolgenden Requests prüft der Server die Session‑ID im Speicher/DB.
GET /dashboard HTTP/1.1
Host: webapp.example.com
Cookie: SESSIONID=abc123def456

Probleme: Server‑seitiger Zustand (Stateful), Skalierungs‑Herausforderung bei verteilten Systemen.

5. Token‑basiertes Authentifizieren: Bearer Tokens & JWTs

Bearer Token

Ein Bearer Token ist ein beliebiges Zeichen‑String, das bei jedem Request gesendet wird. Der Server autorisiert den Aufrufer allein anhand des Vorhandenseins des Tokens – „whoever possesses the token gets access“.

GET /api/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer abcdef123456

JSON Web Token (JWT)

Ein JWT besteht aus drei Base64‑URL‑kodierten Teilen: Header, Payload (Claims) und Signature.

// Header
{"alg":"HS256","typ":"JWT"}
// Payload (Claims)
{"sub":"1234567890","name":"John Doe","iat":1516239022,"exp":1516242622}

Der Server kann das Token offline verifizieren – keine Datenbank‑Lookup nötig → stateless und skalierbar.

Access‑Token (kurzlebig) vs. Refresh‑Token (langlebig):

  • Access‑Token: 15 min – 1 h, für API‑Aufrufe.
  • Refresh‑Token: Tage bis Wochen, dient zum Erneuern des Access‑Tokens.

Best Practice: Refresh‑Token im HttpOnly‑Cookie speichern, nicht im localStorage, um XSS‑Angriffe zu vermeiden.

6. OAuth 2.0 – Das Autorisierungs‑Framework

OAuth 2.0 ist kein Authentifizierungs‑Mechanismus, sondern ein Autorisierungs‑Framework. Es definiert, welche Ressourcen ein Client im Auftrag eines Users anfragen darf.

  1. Authorization Code Flow – Nutzer wird zur Consent‑Seite des IdP (z. B. Google) weitergeleitet.
  2. Nach Zustimmung gibt IdP einen Authorization Code zurück.
  3. Client tauscht den Code gegen ein Access‑Token (und optional ein Refresh‑Token) aus.
Client → Authorization Endpoint → User Consent → Authorization Code → Token Endpoint → Access Token

Das erhaltene Access‑Token erlaubt dem Client, z. B. Google‑Drive‑Daten zu lesen – es sagt jedoch nicht, wer der Nutzer ist.

7. OpenID Connect (OIDC) – Authentifizierung auf Basis von OAuth 2.0

OIDC erweitert OAuth 2.0 um ein ID‑Token (ein JWT), das die Identität des Nutzers bestätigt.

  • Ablauf: Wie bei OAuth 2.0, aber zusätzlich wird ein ID‑Token zurückgeliefert.
  • Das ID‑Token enthält Claims wie sub, email, name und ist signiert.

Damit kann die Anwendung das ID‑Token verifizieren und den Nutzer authentifizieren, während das Access‑Token weiterhin für Autorisierungs‑Zwecke genutzt wird.

8. Single Sign‑On (SSO) – Das Nutzererlebnis

SSO ist kein technisches Authentifizierungs‑Verfahren, sondern ein User‑Experience‑Pattern. Der Nutzer meldet sich einmal bei einem Identity Provider (IdP) an und erhält ein SSO‑Cookie bzw. ein SAML‑Assertion. Dieses Token wird dann von allen verbundenen Diensten akzeptiert.

  • SAML (Security Assertion Markup Language) – XML‑basiertes Protokoll, häufig in Enterprise‑Umgebungen.
  • OIDC – Modernere, JSON‑basierte Alternative zu SAML.

Durch SSO kann ein Nutzer nahtlos auf Gmail, Google‑Drive, YouTube usw. zugreifen, ohne sich erneut einloggen zu müssen.

Fazit

Authentifizierung ist die Grundlage, um die Identität eines Users oder Service zu verifizieren. Die Auswahl der richtigen Methode hängt von Sicherheitsanforderungen, Skalierbarkeit und Anwendungsfall ab:

  • Für interne Tools reicht Basic oder API‑Key.
  • Für public APIs sind JWT‑basierte Bearer Tokens mit Access‑/Refresh‑Token‑Modell ideal.
  • Für Web‑Apps mit vielen Session‑basierten Interaktionen kann eine klassische Session‑Lösung funktionieren, jedoch mit zusätzlicher Skalierungs‑Strategie (z. B. Redis).
  • OAuth 2.0 + OpenID Connect liefern ein modernes, deklaratives Modell für Drittanbieter‑Zugriff und Nutzer‑Login.

Kennst du den Unterschied zwischen Authentifizierung und Autorisierung? Dann bist du bereit, das passende Sicherheitsmodell für deine Anwendung zu wählen.

Weiterführende Links

  • [RFC 7616 – HTTP Digest Access Authentication][1]
  • [JWT.io – Einführung in JSON Web Tokens][2]
  • [OAuth 2.0 – The RFC][3]
  • [OpenID Connect – Specification][4]
  • [OWASP – Secure Session Management][5]

Quellen