Ist OAuth dasselbe wie Authentifizierung?

Nein. OAuth ist eine Autorisierung – sie gewährt dem Client die Berechtigung, auf Ressourcen zuzugreifen. OpenID Connect, basierend auf OAuth, fügt Authentifizierung hinzu. „Mit Google anmelden“ ist OIDC; „Google Kalender verbinden“ kann entweder sein, je nachdem, ob die App wissen muss, wer Sie sind, oder nur Zugriff auf Ihre Daten benötigt.

Soll ich OAuth verwenden oder Passwörter speichern?

Verwenden Sie OAuth, wo immer möglich. Das Speichern von Benutzerkennwörtern bedeutet, dass Sie die gesamte Verantwortung für Hashing, Salt, Reaktion auf Sicherheitsverletzungen, Kennwortwiederherstellung und 2FA übernehmen. Das Delegieren an Google/Apple/Microsoft/GitHub über OAuth entlastet all das. Der Nachteil besteht darin, dass Ihre Benutzer Konten bei diesen Anbietern benötigen.

Warum können OAuth-Token widerrufen werden, Passwörter jedoch nicht?

Token verweisen auf einen Eintrag in der Datenbank des Autorisierungsservers. Durch den Widerruf des Eintrags wird das Token sofort ungültig. Passwörter sind Wissen – Sie können das Passwort wechseln und eine erneute Authentifizierung erzwingen, aber das alte Passwort bleibt gültig, bis Sie dies tun.

Was ist der Unterschied zwischen OAuth 2.0 und OAuth 1.0?

OAuth 1.0 (2007) verwendete kryptografische Signaturen für jede Anfrage. OAuth 2.0 (2012) setzt für die Transportsicherheit auf TLS und verwendet Inhabertoken. OAuth 2.0 ist einfacher zu implementieren und in nahezu jeder modernen API enthalten. OAuth 1.0 is essentially deprecated.

Sind OAuth-Token gefährlich, wenn sie durchgesickert sind?

Ja – jeder, der über das Token verfügt, hat den gewährten Zugriff, bis dieser abläuft oder widerrufen wird. Abhilfemaßnahmen: kurze Lebensdauer von Zugriffstoken (typischerweise 1 Stunde), sicherere Speicherung von Aktualisierungstoken, Minimierung des Umfangs, Überwachungsprotokollierung. Behandeln Sie Zugriffstoken während ihrer Gültigkeitsdauer mit der gleichen Sorgfalt wie Passwörter.

OAuth 2.0 erklärt: Wie „Mit Google anmelden“ tatsächlich funktioniert

Jede Schaltfläche „Mit Google anmelden“, jeder Link „Verbinden Sie Ihr Twitter-Konto“ und jede API-Integration zwischen modernen Diensten basiert auf OAuth. Das Protokoll ersetzt die gemeinsame Nutzung von Passwörtern durch einen Fluss von Token und Zustimmungsbildschirmen, und das Verständnis der beweglichen Teile entmystifiziert eine Kategorie von Angriffen und Annehmlichkeiten zugleich.

Der vollständige Artikeltext ist unten in englischer Sprache aufgeführt.

OAuth 2.0 ist ein Autorisierungsframework, das einer Anwendung im Namen eines Benutzers eingeschränkten Zugriff auf die Ressourcen einer anderen Anwendung ermöglicht – ohne jemals das Passwort des Benutzers zu sehen. Der klassische Anwendungsfall: Eine Kalender-App, die Ihren Google Kalender lesen muss, sollte nicht die Angabe Ihres Google-Passworts erfordern. Mit OAuth können Sie der App stattdessen ein bereichsbezogenes, widerrufliches Token gewähren.

XPLZ4 (z. B. ein Kalender-Viewer eines Drittanbieters)

Autorisierungsserver – der Dienst, der Sie authentifiziert und Token ausstellt (z. B. der OAuth-Endpunkt von Google) API)

Der Autorisierungscode-Ablauf

Der standardmäßige serverseitige Ablauf, vereinfacht:

Sie klicken in der Client-App auf „Google Kalender verbinden“.
Der Client leitet Ihren Browser mit folgenden Parametern an den Autorisierungsserver von Google weiter: client_id, Redirect_uri, Scope (calendar.read), Status (CSRF Token).
Sie authentifizieren sich bei Google, wenn Sie noch nicht angemeldet sind.
Google zeigt Ihnen einen Einwilligungsbildschirm an: „CalendarViewer möchte Ihren Kalender lesen. Zulassen?“ Google leitet Ihren Browser mit einem einmaligen Autorisierungscode zurück zur „redirect_uri“ des Clients.

Die entscheidende Sicherheitseigenschaft: Ihr Passwort berührt niemals die Client-App. Der Client erhält ein bereichsbezogenes Token, das Sie jederzeit im Google-Konto-Dashboard widerrufen können. Seitdem wurden mehrere Erweiterungs-RFCs und Best-Practice-Dokumente hinzugefügt OAuth 2.0. OAuth allein stellt ein undurchsichtiges Zugriffstoken bereit; OIDC fügt ein ID-Token (ein JWT) hinzu, das den Benutzer authentifiziert. Die meisten „Anmelden mit...“-Schaltflächen verwenden OIDC, nicht einfaches OAuth. XPLZ66 Mit PKCE-Erweiterung, die auch von Mobil- und SPA-Apps verwendet wird. Anfällig für Token-Lecks; ersetzt durch Autorisierungscode + PKCE.

Resource Owner Password Credentials (selten verwendet) – der Client sammelt das Passwort des Benutzers und tauscht es gegen ein Token ein. Sollte nur in Legacy-Migrationsszenarien verwendet werden.

Client-Anmeldeinformationen – für Maschine-zu-Maschine, wenn kein Benutzer vorhanden ist. Der Client authentifiziert sich und erhält ein Token für seine eigenen Ressourcen.

Gerätecode – für Geräte ohne Browser (Fernseher, IoT). Das Gerät zeigt einen Code an; Der Benutzer autorisiert von einem Telefon oder Laptop aus „pixie“) verhindert Angriffe zum Abfangen von Autorisierungscodes. Der Client generiert ein zufälliges Geheimnis, hasht es und sendet den Hash in der Autorisierungsanfrage. Beim Austausch des Codes wird das ursprüngliche Geheimnis gesendet. Der Autorisierungsserver überprüft die Hash-Übereinstimmungen. Jeder Angreifer, der den Code abfängt, kann ihn ohne das ursprüngliche Geheimnis nicht austauschen.

PKCE gilt jetzt als obligatorisch für alle OAuth-Clients – öffentlich (Browser, Mobil) und vertraulich (serverseitig).h2>Scopes

Tokens werden mit bestimmten Bereichen ausgegeben – den Aktionen, die sie ausführen dürfen. Die typischen Bereiche von Google sehen wie https://www.googleapis.com/auth/calendar.readonly aus. The client requests scopes; Der Benutzer sieht sie auf dem Zustimmungsbildschirm und stimmt zu oder lehnt sie ab. Das Prinzip der geringsten Berechtigung: Fragen Sie nur nach den Bereichen, die Sie tatsächlich benötigen.

XPLZ5 OAuth-Flows sind anfällig für CSRF – ein Angreifer bringt das Opfer dazu, einen OAuth-Flow zu vervollständigen, der das Konto des Angreifers mit der Sitzung des Opfers verknüpft localStorage und jede XSS-Schwachstelle aufweist, können Angreifer sie stehlen.

XPLZ25 Der Benutzer, der dazu verpflichtet ist, auf Zustimmungsbildschirmen auf „Zulassen“ zu klicken, gewährt Zugriff ohne Prüfung.

XPLZ29 Widerrufen Sie diejenigen, die Sie nicht verwenden.

Lesen Sie die Bereiche des Einwilligungsbildschirms, bevor Sie Zugriff gewähren. „Kalender verwalten“ unterscheidet sich von „Kalender anzeigen“.

Häufig gestellte Fragen

Ist OAuth dasselbe wie Authentifizierung?: Nein. OAuth ist eine Autorisierung – sie gewährt dem Client die Berechtigung, auf Ressourcen zuzugreifen. OpenID Connect, basierend auf OAuth, fügt Authentifizierung hinzu. „Mit Google anmelden“ ist OIDC; „Google Kalender verbinden“ kann entweder sein, je nachdem, ob die App wissen muss, wer Sie sind, oder nur Zugriff auf Ihre Daten benötigt.
Soll ich OAuth verwenden oder Passwörter speichern?: Verwenden Sie OAuth, wo immer möglich. Das Speichern von Benutzerkennwörtern bedeutet, dass Sie die gesamte Verantwortung für Hashing, Salt, Reaktion auf Sicherheitsverletzungen, Kennwortwiederherstellung und 2FA übernehmen. Das Delegieren an Google/Apple/Microsoft/GitHub über OAuth entlastet all das. Der Nachteil besteht darin, dass Ihre Benutzer Konten bei diesen Anbietern benötigen.
Warum können OAuth-Token widerrufen werden, Passwörter jedoch nicht?: Token verweisen auf einen Eintrag in der Datenbank des Autorisierungsservers. Durch den Widerruf des Eintrags wird das Token sofort ungültig. Passwörter sind Wissen – Sie können das Passwort wechseln und eine erneute Authentifizierung erzwingen, aber das alte Passwort bleibt gültig, bis Sie dies tun.
Was ist der Unterschied zwischen OAuth 2.0 und OAuth 1.0?: OAuth 1.0 (2007) verwendete kryptografische Signaturen für jede Anfrage. OAuth 2.0 (2012) setzt für die Transportsicherheit auf TLS und verwendet Inhabertoken. OAuth 2.0 ist einfacher zu implementieren und in nahezu jeder modernen API enthalten. OAuth 1.0 is essentially deprecated.
Sind OAuth-Token gefährlich, wenn sie durchgesickert sind?: Ja – jeder, der über das Token verfügt, hat den gewährten Zugriff, bis dieser abläuft oder widerrufen wird. Abhilfemaßnahmen: kurze Lebensdauer von Zugriffstoken (typischerweise 1 Stunde), sicherere Speicherung von Aktualisierungstoken, Minimierung des Umfangs, Überwachungsprotokollierung. Behandeln Sie Zugriffstoken während ihrer Gültigkeitsdauer mit der gleichen Sorgfalt wie Passwörter.