Was OAuth 2.0 regelt und was nicht

OAuth 2.0 ist in RFC 6749 definiert und beschreibt ein Autorisierungs-Framework, kein Authentifizierungsverfahren. Es löst das Problem, dass eine Anwendung (der Client) im Namen eines Nutzers (des Resource Owner) auf eine geschützte API (den Resource Server) zugreifen soll, ohne dessen Anmeldedaten zu erhalten. Stattdessen stellt ein Authorization Server dem Client ein Access Token aus, das begrenzten Zugriff gewährt.

Das Framework kennt mehrere Wege, an ein Token zu kommen (Grant Types):

  • Authorization Code - für Anwendungen mit Nutzerinteraktion, der empfohlene Standardweg.
  • Client Credentials - für Maschine-zu-Maschine-Zugriff ohne Nutzer.
  • Implicit und Resource Owner Password Credentials - historische Verfahren, heute abgeraten (siehe unten).

Wichtig: OAuth selbst sagt nichts darüber aus, wer der Nutzer ist. Ein Access Token belegt nur, dass dem Client ein bestimmter Zugriff erlaubt wurde, nicht die Identität des angemeldeten Nutzers. Das OWASP-Projekt formuliert dies in API2:2023 ausdrücklich: OAuth ist keine Authentifizierung, und API-Keys sind es ebenfalls nicht. Wer ein Access Token als Identitätsnachweis missbraucht, baut sich Broken Authentication ein.

MerkmalID TokenAccess Token
ZweckAuthentifizierung: belegt, wer sich angemeldet hatAutorisierung: gewährt Zugriff auf eine API
Empfänger (Audience)Der Client (OIDC Relying Party)Der Resource Server (die API)
FormatImmer ein JWT mit definierten Claims (iss, sub, aud, exp)Für den Client undurchsichtig (oft JWT, auch opak möglich)
Definiert inOpenID Connect Core 1.0OAuth 2.0 (RFC 6749), Nutzung als Bearer in RFC 6750
Typischer FehlerWird fälschlich der API als Zugriffstoken vorgelegtWird fälschlich als Identitätsnachweis interpretiert

ID Token versus Access Token in OpenID Connect

Authorization Code Flow mit PKCE

Der Authorization Code Flow trennt zwei Kanäle: Über den Browser (Front-Channel) erhält der Client nur einen kurzlebigen Authorization Code, das eigentliche Token wird anschließend über eine direkte Server-zu-Server-Anfrage (Back-Channel) am token-Endpunkt eingelöst. So gelangt das Access Token nie in die URL oder den Browser-Verlauf.

Der Ablauf in Schritten:

  1. Der Client leitet den Nutzer mit response_type=code zum authorize-Endpunkt um.
  2. Nach Anmeldung und Zustimmung wird der Nutzer mit einem code zurück zur registrierten redirect_uri geleitet.
  3. Der Client tauscht den code am token-Endpunkt gegen ein Access Token (und optional ein Refresh Token).

PKCE (Proof Key for Code Exchange, RFC 7636) härtet diesen Flow gegen das Abfangen und Einschleusen des Codes ab. Der Client erzeugt vor dem Start ein zufälliges Geheimnis (code_verifier), sendet beim Autorisierungsaufruf nur dessen Hash (code_challenge) und muss beim Token-Tausch den passenden code_verifier nachweisen. Ein abgefangener Code allein ist damit wertlos. Ursprünglich für native Apps entwickelt, gilt PKCE heute laut RFC 9700 und dem OAuth-2.1-Entwurf für alle Client-Typen, einschließlich Web-Anwendungen und vertraulicher Clients, da auch sie für Code-Injection-Angriffe anfällig sind.

Token-Typen, Scopes und Refresh Tokens

Access Token: Das eigentliche Zugriffstoken für die API. Meist als Bearer Token verwendet (RFC 6750): Wer es besitzt, darf es nutzen, ein kryptographischer Besitznachweis ist nicht erforderlich. Übermittelt wird es im Header Authorization: Bearer . Access Tokens sollten kurzlebig sein.

Refresh Token: Ein langlebigeres Token, mit dem der Client am Authorization Server ein neues Access Token holt, wenn das alte abläuft, ohne erneute Nutzerinteraktion. Refresh Tokens sind laut RFC 6749 ausschließlich für den Authorization Server bestimmt und werden niemals an den Resource Server gesendet. Mit ihnen lassen sich auch Tokens mit gleichem oder engerem Scope anfordern.

Scopes: Über den Parameter scope fordert der Client einen Berechtigungsumfang an (etwa read, write). Der Authorization Server darf den angefragten Scope ganz oder teilweise ignorieren und muss bei Abweichung den tatsächlich gewährten Scope in der Antwort zurückgeben. Scopes sind grobgranulare Berechtigungen, sie ersetzen keine objektbezogene Autorisierung: Welcher konkrete Datensatz zugänglich ist, prüft die API zusätzlich selbst, sonst drohen BOLA-Schwachstellen.

OpenID Connect: die Identitätsschicht

OpenID Connect (OIDC) ist eine Schicht oberhalb von OAuth 2.0, die das fehlende Stück liefert: einen standardisierten Nachweis, wer sich angemeldet hat. Kern ist das ID Token, ein JWT mit Claims über die Authentifizierung des Endnutzers. Pflichtfelder sind unter anderem iss (ausstellender Server), sub (eindeutige Nutzer-ID), aud (für welchen Client das Token bestimmt ist) sowie Zeitangaben.

Der entscheidende Unterschied:

  • Das ID Token richtet sich an den Client und beantwortet die Frage der Authentifizierung. Es ist nicht dafür gedacht, der API als Zugriffstoken vorgelegt zu werden.
  • Das Access Token richtet sich an die API (den Resource Server) und beantwortet die Frage der Autorisierung. Sein Format ist für den Client undurchsichtig.

Möchte ein Client zusätzliche Profildaten, ruft er mit dem Access Token den UserInfo-Endpunkt auf, der Claims über den Endnutzer zurückgibt. Ein verbreiteter Fehler ist, das ID Token und das Access Token zu vertauschen, etwa das ID Token an die API zu senden oder umgekehrt aus einem Access Token Identitätsdaten abzuleiten, die es gar nicht garantiert.

Häufige Fehler und der Bezug zu Broken Authentication

Die meisten OAuth-/OIDC-Schwachstellen entstehen nicht im Protokoll selbst, sondern in fehlerhafter Implementierung und ordnen sich bei OWASP unter API2:2023 Broken Authentication ein.

  • Impliziter Flow: Beim Implicit Grant (response_type=token) liefert der Authorization Server das Access Token direkt in der Umleitungs-URL aus. Tokens in der URL landen in Logs, Verläufen und im Referer und lassen sich nicht an einen Client binden. RFC 9700 rät davon ab, OAuth 2.1 entfernt den impliziten Flow ganz. Empfohlen ist stattdessen der Authorization Code Flow mit PKCE.
  • Token in der URL: Auch unabhängig vom impliziten Flow ist das Mitgeben von Access Tokens als Query-Parameter problematisch. RFC 6750 stuft die URI-Query-Parameter-Methode als SHOULD NOT ein, weil die URL mit hoher Wahrscheinlichkeit protokolliert wird. Tokens gehören in den Authorization-Header.
  • Fehlende Audience-Prüfung: Die API muss prüfen, dass das vorgelegte Token tatsächlich für sie bestimmt ist. RFC 9700 empfiehlt, Access Tokens per aud-Claim auf einen bestimmten Resource Server zu beschränken. Ohne diese Prüfung kann ein für Dienst A ausgestelltes Token bei Dienst B akzeptiert werden (Token-Reuse).
  • Fehlende Scope- und Signaturprüfung: Wird der Scope nicht serverseitig durchgesetzt oder die Signatur und das Ablaufdatum des Tokens nicht validiert, sind Privilegieneskalation und gefälschte Tokens möglich. Mehr dazu unter JWT-Angriffe.
  • Lockere redirect_uri-Prüfung: OAuth 2.1 verlangt exakten String-Vergleich der Redirect-URI. Platzhalter oder Teilstring-Abgleiche ermöglichen das Umleiten von Codes oder Tokens an Angreifer.

OAuth 2.1: Konsolidierung der Best Practices

OAuth 2.1 ist kein neues Protokoll, sondern eine Konsolidierung: Der Internet-Draft draft-ietf-oauth-v2-1 fasst RFC 6749, RFC 6750 und die seither etablierten Sicherheitsempfehlungen (insbesondere RFC 9700) zu einem Dokument zusammen und entfernt veraltete, unsichere Teile.

Die wichtigsten Festlegungen gegenüber OAuth 2.0:

  • PKCE ist Pflicht für den Authorization Code Grant, für alle Client-Typen.
  • Der Implicit Grant (response_type=token) entfällt.
  • Der Resource Owner Password Credentials Grant (Weitergabe von Passwörtern an den Client) entfällt.
  • Redirect-URIs müssen per exaktem String-Vergleich geprüft werden.
  • Bearer Tokens dürfen nicht mehr im Query-String der URL übertragen werden.

Für eine sichere Umsetzung gilt damit als Faustregel: Authorization Code Flow mit PKCE, kurzlebige Access Tokens, strikte Prüfung von Signatur, aud, exp und Scope auf der API-Seite, und eine klare Trennung von ID Token (Authentifizierung) und Access Token (Autorisierung).

Quellen

Weiterlesen
API2Broken Authentication Angriffe & RisikenJWT-Angriffe GrundlagenAPI-Authentifizierung