LF08

API-Authentifizierung#

Da APIs oft über das öffentliche Internet erreichbar sind und Zugriff auf sensible Daten oder Funktionen erlauben, muss jede Anfrage eindeutig einem berechtigten Aufrufer zugeordnet werden können. Die Authentifizierung stellt fest, wer eine Anfrage stellt, die anschließende Autorisierung entscheidet, was dieser Aufrufer tun darf.

Warum APIs Authentifizierung brauchen#

Ohne Authentifizierungsmechanismus könnte jeder, der die URI einer API kennt, beliebige Daten abrufen, verändern oder löschen. Typische Ziele einer API-Authentifizierung:

  • Zugriffskontrolle: Nur berechtigte Clients/Nutzer erhalten Zugriff
  • Nachvollziehbarkeit: Anfragen lassen sich einem Konto/System zuordnen (Logging, Abrechnung)
  • Ratenbegrenzung: Missbrauch (z. B. Massenabfragen) kann pro Nutzer begrenzt werden
  • Schutz sensibler Daten: Personenbezogene oder geschäftskritische Daten bleiben vor unbefugtem Zugriff geschützt

Gängige Verfahren im Überblick#

VerfahrenFunktionsweiseSicherheitsniveauTypischer Einsatz
API-KeyFester, geheimer Schlüssel wird bei jeder Anfrage mitgeschickt (z. B. als Header)Niedrig bis mittel — Key kann bei Diebstahl missbraucht werdenEinfache Server-zu-Server-Kommunikation, öffentliche Daten-APIs
Basic AuthBenutzername:Passwort werden Base64-kodiert im HTTP-Header übertragenNiedrig ohne TLS — Zugangsdaten sind nur kodiert, nicht verschlüsseltInterne Tools, einfache Skripte, immer nur über HTTPS
Bearer Token / JWTClient sendet ein zeitlich begrenztes Token, das der Server ausstellt und prüftMittel bis hoch, abhängig von Token-Lebensdauer und ÜbertragungssicherheitModerne Web- und Mobile-APIs
OAuth 2.0Standardisierter Autorisierungs-Flow: Nutzer gewährt einer Anwendung begrenzten Zugriff, ohne das eigene Passwort weiterzugebenHoch — etablierter IndustriestandardAnmeldung über Drittanbieter (“Login mit Google/Microsoft”), Zugriff auf geschützte Nutzerdaten durch Drittanwendungen

API-Key#

Der einfachste Ansatz: Der API-Anbieter vergibt einen geheimen Schlüssel, den der Client bei jeder Anfrage mitschickt, meist als Header (X-API-Key: abc123...). Der Key identifiziert den Aufrufer, beweist aber für sich genommen keine Identität einer natürlichen Person — er sollte daher nie im Quellcode oder in Client-seitigem JavaScript sichtbar landen.

Basic Auth#

Bei Basic Auth werden Benutzername und Passwort kombiniert, Base64-kodiert (nicht verschlüsselt!) und im Authorization-Header übertragen. Da Base64 trivial dekodierbar ist, ist Basic Auth nur in Kombination mit HTTPS/TLS sicher nutzbar.

Bearer Token und das JWT-Konzept#

Ein Bearer Token ist ein Zugangstoken, das der Inhaber (“bearer”) einfach vorzeigt, um Zugriff zu erhalten — vergleichbar mit einer Fahrkarte. Ein weit verbreitetes Tokenformat ist das JWT (JSON Web Token): Es enthält in kodierter, digital signierter Form Informationen über den Nutzer und die Gültigkeitsdauer. Der Server kann die Signatur prüfen, ohne den Sitzungszustand selbst speichern zu müssen — das passt gut zum zustandslosen Prinzip von REST-APIs.

OAuth 2.0 — Grundidee des Autorisierungs-Flows#

OAuth 2.0 löst ein häufiges Problem: Eine Drittanwendung soll im Namen eines Nutzers auf geschützte Ressourcen zugreifen dürfen (z. B. eine Kalender-App auf die Google-Kontakte), ohne dass der Nutzer sein Passwort an die Drittanwendung weitergibt. Stattdessen meldet sich der Nutzer direkt beim Anbieter (z. B. Google) an und erteilt dort eine begrenzte Freigabe. Die Drittanwendung erhält anschließend nur ein Access Token mit eng begrenzten Rechten (Scope) und begrenzter Gültigkeitsdauer — nie das eigentliche Passwort.

Vereinfachter API-Key-Ablauf#

sequenceDiagram
  actor Client
  participant API as API-Server

  Client->>API: Anfrage + Header "X-API-Key: abc123"
  API->>API: Key gegen Datenbank prüfen
  alt Key gültig
    API-->>Client: 200 OK + Daten
  else Key ungültig/fehlt
    API-->>Client: 401 Unauthorized
  end

Vereinfachter OAuth-2.0-Ablauf#

sequenceDiagram
  actor Nutzer
  participant App as Drittanwendung
  participant Auth as Autorisierungsserver
  participant API as Geschützte API

  Nutzer->>App: Möchte Funktion nutzen, die Zugriff erfordert
  App->>Auth: Weiterleitung zur Anmeldung
  Nutzer->>Auth: Anmeldung + Freigabe erteilen
  Auth-->>App: Access Token
  App->>API: Anfrage + Access Token
  API-->>App: Freigegebene Daten

Wann welches Verfahren sinnvoll ist#

  • API-Key: Wenn nur grob unterschieden werden muss, welches System zugreift, und kein feingranulares Nutzer-Berechtigungsmodell nötig ist
  • Basic Auth: Für einfache, interne Anwendungsfälle, immer nur zusammen mit HTTPS
  • Bearer Token/JWT: Wenn Zustandslosigkeit wichtig ist und der Server keine Sitzungen verwalten soll
  • OAuth 2.0: Wenn eine Anwendung im Namen eines Nutzers auf Daten eines anderen Anbieters zugreifen soll, ohne dessen Zugangsdaten zu erhalten

Prüfungsbeispiele#

„Warum sollte Basic Auth nur über HTTPS eingesetzt werden?"

→ Weil Benutzername und Passwort bei Basic Auth lediglich Base64-kodiert, nicht verschlüsselt übertragen werden. Ohne TLS könnte jeder, der den Datenverkehr mitschneidet, die Zugangsdaten trivial dekodieren.

„Eine Kalender-App soll auf die Kontakte eines Nutzers bei einem anderen Anbieter zugreifen, ohne dessen Passwort zu kennen. Welches Verfahren ist dafür vorgesehen?"

→ OAuth 2.0 — der Nutzer meldet sich direkt beim Anbieter an und erteilt der Kalender-App ein begrenztes Access Token, das Passwort bleibt geheim.

„Was ist der Vorteil eines Bearer Tokens gegenüber einer klassischen serverseitigen Sitzung für eine REST-API?"

→ Der Server muss keinen Sitzungszustand speichern — das Token selbst enthält alle nötigen, signierten Informationen. Das passt zum zustandslosen (stateless) Prinzip von REST und erleichtert die Skalierung über mehrere Server.

Quiz#

❓ Welches Authentifizierungsverfahren überträgt Zugangsdaten lediglich Base64-kodiert und ist deshalb nur zusammen mit TLS/HTTPS sicher?
❓ Welche Aussagen zu OAuth 2.0 treffen zu?
❓ Warum passt ein Bearer Token wie JWT gut zum zustandslosen Prinzip von REST-APIs?

Siehe auch#

  • rest-api-grundlagen — REST-Prinzipien, auf denen die meisten authentifizierten APIs aufbauen
  • verschluesselung — TLS/HTTPS als Grundlage sicherer Token-/Passwortübertragung
  • zugriffskontrolle — Authentifizierung und Autorisierung als allgemeines Sicherheitskonzept
  • dsgvo — Schutz personenbezogener Daten bei API-Zugriffen

Ressourcen#