OAuth 2.0
Was ist OAuth 2.0?
OAuth 2.0 ist ein offener Standard, mit dem Anwendungen begrenzten Zugriff auf geschützte Daten oder Funktionen erhalten. Nutzer geben dabei kein Passwort an die zugreifende Anwendung weiter. Stattdessen stellt ein Autorisierungsserver ein zeitlich oder sachlich begrenztes Zugriffstoken für festgelegte Berechtigungen aus.
OAuth 2.0, sinngemäß offene Autorisierung, trennt die Zustimmung des Nutzers vom eigentlichen Zugriff auf eine API. Ein typisches Beispiel ist eine Anwendung, die auf ein Werbekonto, einen Cloudspeicher oder ein Analyseprofil zugreifen soll. Der Nutzer meldet sich beim jeweiligen Plattformanbieter an und bestätigt dort, welche Zugriffsrechte die Anwendung erhält.
OAuth 2.0 einfach erklärt
OAuth 2.0 löst ein konkretes Sicherheitsproblem: Eine externe Anwendung benötigt Zugriff auf bestimmte Daten, soll dafür aber weder das Passwort des Nutzers kennen noch uneingeschränkte Rechte erhalten. Der Plattformanbieter gibt deshalb ein Zugriffstoken aus. Dieses Token kann auf einzelne Funktionen beschränkt, zeitlich befristet und unabhängig vom Passwort widerrufen werden.
OAuth 2.0 definiert für diesen Ablauf vier Rollen:
Der Authorization Server und der Resource Server können technisch zum selben Dienst gehören. Die Rollen bleiben trotzdem getrennt, weil die Token-Ausstellung und die Bereitstellung geschützter Daten unterschiedliche Aufgaben erfüllen.
So funktioniert OAuth 2.0
Bei Webanwendungen wird meistens der Authorization Code Flow verwendet. Die Anwendung leitet den Nutzer zunächst zum Autorisierungsserver weiter. Nach Anmeldung und Zustimmung erhält die Anwendung einen kurzlebigen Autorisierungscode. Diesen Code tauscht das Backend über eine direkte Verbindung gegen ein Zugriffstoken aus.
| Schritt | Vorgang | Sicherheitszweck |
|---|---|---|
| 1 | Der Client startet die Autorisierungsanfrage. | Gewünschte Berechtigungen und Rücksprungadresse werden festgelegt. |
| 2 | Der Nutzer meldet sich beim Anbieter an. | Das Passwort bleibt beim Autorisierungsserver. |
| 3 | Der Nutzer stimmt den angeforderten Rechten zu. | Der Zugriff wird auf definierte Scopes begrenzt. |
| 4 | Der Client erhält einen Autorisierungscode. | Der Code ist nur für den vorgesehenen Austausch bestimmt. |
| 5 | Das Backend tauscht den Code gegen ein Token. | Die API erhält bei späteren Aufrufen kein Nutzerpasswort. |
Tokens und Scopes verstehen
Das Access Token weist gegenüber einer API nach, dass der Client eine bestimmte Berechtigung erhalten hat. Die API prüft das Token bei jeder Anfrage. Das Format ist durch OAuth 2.0 nicht fest vorgeschrieben. Ein Token kann daher eine strukturierte Zeichenfolge wie ein JSON Web Token, kurz JWT, oder ein undurchsichtiger zufälliger Wert sein.
Ein Refresh Token ermöglicht die Ausstellung eines neuen Access Tokens, ohne dass sich der Nutzer erneut anmelden muss. Refresh Tokens besitzen deshalb einen höheren Schutzbedarf als kurzlebige Access Tokens. Sie gehören in einen geschützten serverseitigen Speicher und dürfen weder in öffentlich erreichbaren Quellcode noch in Analyseprotokolle oder URLs gelangen.
Scopes beschreiben den genehmigten Zugriffsumfang. Eine Integration kann beispielsweise Leserechte für Berichte anfordern, ohne Schreibrechte für Kontoeinstellungen zu erhalten. Der Grundsatz der minimalen Berechtigung reduziert die Folgen eines kompromittierten Tokens: Je kleiner der Scope, desto geringer ist der mögliche Zugriff.
OAuth 2.0 Flows im Vergleich
OAuth 2.0 unterstützt verschiedene Abläufe für unterschiedliche Anwendungstypen. Die Auswahl hängt davon ab, ob ein Nutzer beteiligt ist, ob der Client ein Geheimnis sicher speichern kann und auf welchem Gerät die Autorisierung stattfindet.
PKCE steht für Proof Key for Code Exchange. Der Client erzeugt vor der Autorisierung einen zufälligen Code Verifier und sendet daraus eine abgeleitete Code Challenge. Beim Token-Austausch muss derselbe Client den passenden Code Verifier vorlegen. Ein abgefangener Autorisierungscode allein reicht dadurch nicht für den Zugriff aus.
Autorisierung ist keine Anmeldung
OAuth 2.0 wird häufig als Anmeldeverfahren bezeichnet. Das ist fachlich ungenau. OAuth 2.0 regelt die Autorisierung eines Zugriffs, liefert aber allein keine standardisierte Aussage über die Identität des Nutzers. Ein gültiges Access Token bestätigt deshalb primär eine Berechtigung und nicht zwingend, wer sich angemeldet hat.
OpenID Connect ergänzt OAuth 2.0 um eine standardisierte Identitätsschicht. Dabei stellt der Anbieter zusätzlich ein ID Token mit Informationen über die Anmeldung und den Nutzer aus. Für eine Funktion wie „Mit einem bestehenden Konto anmelden“ ist OpenID Connect daher der passende Standard, während OAuth 2.0 den anschließenden API-Zugriff regelt.
Abgrenzung zu API-Key und SAML
Der Unterschied zwischen OAuth 2.0 und einem API-Key liegt in der Delegation. Ein API-Key identifiziert meist ein Projekt oder eine Anwendung und besitzt häufig statisch vergebene Rechte. OAuth 2.0 kann dagegen die Zustimmung eines Nutzers, begrenzte Scopes, Token-Ablaufzeiten und einen kontrollierten Widerruf abbilden.
SAML dient vor allem dem webbasierten Single Sign-on zwischen einem Identitätsanbieter und Unternehmensanwendungen. OAuth 2.0 konzentriert sich auf den Zugriff auf APIs. OpenID Connect eignet sich für moderne Anmeldeprozesse auf Basis von OAuth 2.0. Die Standards können im selben Unternehmen parallel eingesetzt werden, weil sie unterschiedliche Aufgaben abdecken.
OAuth 2.0 im Online-Marketing
OAuth 2.0 begegnet Marketing-Teams beim Verbinden von Analyseplattformen, Werbekonten, Content-Management-Systemen und Reporting-Diensten. Der Standard erlaubt einer Anwendung, Daten über eine API abzurufen, ohne Zugangsdaten des Plattformkontos dauerhaft zu speichern. Das erleichtert kontrollierte Integrationen zwischen SEO, SEA und GEO, sofern Scopes und Kontozuordnungen sauber dokumentiert sind.
Für SEO und technische Prüfungen von Google-Ads-Zielseiten wird OAuth 2.0 relevant, wenn Daten aus Plattformen automatisiert zusammengeführt werden. Bei einer professionellen Website-Entwicklung müssen außerdem Redirect URIs, Token-Speicherung und Fehlerbehandlung bereits im Integrationskonzept berücksichtigt werden.
Typische Fehler bei OAuth 2.0
Eine falsch konfigurierte Redirect URI kann Autorisierungscodes an ein unerwünschtes Ziel senden. Der Autorisierungsserver sollte deshalb nur zuvor registrierte und exakt übereinstimmende Rücksprungadressen akzeptieren. Offene Weiterleitungen innerhalb der Zielseite müssen ebenfalls ausgeschlossen werden, weil sie einen korrekt zugestellten Code nachträglich umleiten können.
Ein weiterer Fehler sind zu weit gefasste Scopes. Fordert eine Reporting-Anwendung zusätzlich Verwaltungsrechte an, vergrößert sich das Schadenspotenzial ohne funktionalen Nutzen. Dokumentiere deshalb pro Integration, welche Daten benötigt werden, welcher Client darauf zugreift und wie sich die Berechtigung widerrufen lässt. Ein technisches SEO-Audit kann ergänzend klären, ob geschützte Bereiche, Weiterleitungen oder Anmeldeprozesse das Crawling öffentlich bestimmter Inhalte beeinflussen.
Häufige Fragen zu OAuth 2.0
Ist OAuth 2.0 ein Anmeldeverfahren?
OAuth 2.0 regelt in erster Linie die Autorisierung von Zugriffen. Für eine standardisierte Anmeldung und die Übermittlung der Nutzeridentität wird OAuth 2.0 üblicherweise mit OpenID Connect ergänzt.
Wie lange ist ein OAuth-Token gültig?
OAuth 2.0 schreibt keine feste Gültigkeitsdauer vor. Der jeweilige Anbieter legt fest, wann ein Access Token abläuft und ob ein Refresh Token für die Erneuerung ausgegeben wird.
Ist ein Access Token immer ein JWT?
Nein. OAuth 2.0 legt das Format des Access Tokens nicht fest. Ein Anbieter kann ein JWT oder einen undurchsichtigen zufälligen Token verwenden.
Braucht jede OAuth-Anwendung ein Client Secret?
Nein. Browseranwendungen und mobile Apps können ein eingebautes Geheimnis nicht zuverlässig schützen. Solche öffentlichen Clients verwenden deshalb den Authorization Code Flow mit PKCE.
Kann ein OAuth-Zugriff widerrufen werden?
Ja. Nutzer oder Administratoren können einer Anwendung die erteilte Berechtigung entziehen. Der genaue Ablauf und die Auswirkungen auf bestehende Tokens hängen vom jeweiligen Anbieter ab.
Meldet OAuth 2.0 einen Nutzer automatisch ab?
Nein. Das Beenden einer Sitzung, der Widerruf eines Tokens und die Abmeldung beim Identitätsanbieter sind getrennte Vorgänge. Eine Anwendung muss den gewünschten Abmeldeprozess ausdrücklich umsetzen.
Wenn du OAuth-basierte Schnittstellen im Rahmen einer Website oder Marketing-Infrastruktur planst, kann eine technische Erstprüfung Anforderungen, Datenflüsse und mögliche Auswirkungen auf SEO und Tracking einordnen.
Kostenlosen Potenzialcheck anfragen
Sie haben noch Fragen?
