Das OAuth 2.0 ist ein offener Standard für delegierten Zugriff: Ein Nutzer erlaubt einer Anwendung, in seinem Namen auf Ressourcen eines Drittsystems zuzugreifen — ohne sein Passwort dorthin weiterzugeben. Anstelle des Passworts erhält die Anwendung ein Access Token, das eng begrenzten Zugriff gewährt.

OAuth 2.0 ist heute die Grundlage praktisch aller „Login mit …"-Mechanismen und der vorherrschende Standard für API-Autorisierung. Wichtig: OAuth 2.0 ist ein Autorisierungsprotokoll, kein Authentifizierungsprotokoll — für Anmeldung wird darauf OpenID Connect (OIDC) als Schicht aufgesetzt.

Beteiligte Rollen

Der Standard kennt vier Rollen:

  • Resource Owner — der Nutzer, dem die Daten gehören.
  • Client — die Anwendung, die im Namen des Nutzers zugreifen möchte.
  • Authorization Server — stellt nach Prüfung der Zustimmung Tokens aus.
  • Resource Server — verwahrt die geschützten Ressourcen und akzeptiert Tokens.

In der Praxis sind Authorization Server und Resource Server oft Teil derselben Plattform.

Tokens

Im laufenden Betrieb sind drei Token-Typen relevant:

  • Access Token — kurzlebig, wird bei jeder API-Anfrage mitgesendet.
  • Refresh Token — langlebiger; mit ihm kann der Client neue Access Tokens beziehen, ohne den Nutzer erneut zu fragen.
  • ID Token — von OpenID Connect ergänzt; enthält Identitätsinformationen über den angemeldeten Nutzer.

Access Tokens sind häufig JWTs, müssen es aber nicht sein — sie können auch undurchsichtige Strings sein, die beim Resource Server nachgeschlagen werden.

Wichtige Flows

OAuth 2.0 kennt mehrere Abläufe, je nach Art des Clients:

  • Authorization Code Flow mit PKCE — der heutige Standard für Web- und Mobile-Apps. Der Client erhält zunächst einen kurzen Code, den er gegen Tokens tauscht. PKCE schützt dabei gegen das Abfangen des Codes.
  • Client Credentials — Maschine-zu-Maschine-Kommunikation ohne beteiligten Nutzer. Der Client weist sich mit eigenen Anmeldedaten aus.
  • Device Authorization Grant — für Geräte ohne Browser, etwa Smart-TVs: ein Code wird angezeigt, der Nutzer bestätigt ihn auf einem zweiten Gerät.
  • Refresh Token Grant — Erneuerung abgelaufener Access Tokens.

Die früher verbreiteten Implicit und Resource Owner Password Credentials Flows gelten als veraltet und werden in der aktuellen Best-Practice-Spezifikation OAuth 2.1 nicht mehr empfohlen.

Tokens sind nicht generisch, sondern auf Scopes beschränkt — etwa read:profile oder write:calendar. Der Nutzer sieht im Consent-Dialog, welche Scopes die Anwendung anfragt, und kann gezielt zustimmen oder ablehnen. Damit lässt sich Zugriff fein granuliert vergeben — und im Schadensfall ebenso fein wieder einziehen.

/ Weiter

Zurück zu IT

Zur Übersicht