Scoped OAuth-Verbindungen

Ausführliche Erklärung

OAuth 2.0 ist ein standardisiertes Autorisierungsprotokoll, das es Anwendungen ermöglicht, im Namen von Benutzern auf geschützte Ressourcen zuzugreifen, ohne dass dabei Passwörter weitergegeben werden müssen. Das Besondere an Scoped OAuth-Verbindungen ist die granulare Kontrolle über Zugriffsrechte: Statt einer Anwendung pauschalen Vollzugriff zu gewähren, definieren Scopes präzise Berechtigungen wie etwa "nur Kalender lesen" oder "E-Mails versenden". Scopes sind technisch gesehen Zeichenketten, die in der Autorisierungsanfrage mitgegeben werden und im ausgestellten Access Token enthalten sind.

Für KMU sind Scoped OAuth-Verbindungen besonders relevant, wenn Drittanwendungen an zentrale Unternehmenssysteme angebunden werden – etwa Marketing-Tools an Google Workspace, CRM-Systeme an Microsoft 365 oder Automatisierungsplattformen an Cloud-Speicher. Durch die Beschränkung auf minimal notwendige Berechtigungen wird das Sicherheitsrisiko deutlich reduziert: Selbst wenn eine angebundene Anwendung kompromittiert wird, kann der Angreifer nur auf die explizit freigegebenen Ressourcen zugreifen. Diese Praxis folgt dem Prinzip der minimalen Rechtevergabe (Principle of Least Privilege), einem etablierten Sicherheitsstandard.

In der Praxis funktioniert dies so: Wenn Sie als Nutzer einer Anwendung die Berechtigung erteilen, auf Ihre Daten zuzugreifen, erscheint ein Zustimmungsdialog, der genau auflistet, welche Scopes angefordert werden – etwa "Ihre E-Mails lesen" oder "Ihre Kontakte bearbeiten". Sie können diese Zustimmung granular erteilen oder verweigern. Die Anwendung erhält dann ein Access Token, das nur die genehmigten Scopes enthält. Ressourcenserver prüfen bei jeder API-Anfrage, ob das vorgelegte Token die erforderlichen Scopes besitzt.

Best Practices für Scoped OAuth-Verbindungen umfassen: Anwendungen sollten nur die minimal notwendigen Scopes anfordern, IT-Verantwortliche sollten regelmäßig erteilte OAuth-Berechtigungen überprüfen und veraltete Verbindungen widerrufen, und Scopes sollten so spezifisch wie möglich definiert werden – beispielsweise "invoices:read" statt eines allgemeinen "invoices"-Scopes, der auch Schreibrechte implizieren könnte. Viele erteilte OAuth-Berechtigungen bleiben jahrelang aktiv und stellen damit eine potenzielle Angriffsfläche dar, wenn sie nicht regelmäßig auditiert werden.

Code-Beispiel

// Beispiel: OAuth 2.0 Authorization Request mit Scopes
const authUrl = `https://accounts.google.com/o/oauth2/v2/auth?
  client_id=${CLIENT_ID}
  &redirect_uri=${REDIRECT_URI}
  &response_type=code
  &scope=https://www.googleapis.com/auth/calendar.readonly
         https://www.googleapis.com/auth/drive.file
  &access_type=offline`;

// Scopes im Access Token prüfen (Server-seitig)
if (token.scopes.includes('calendar.readonly')) {
  // Kalenderzugriff erlaubt
} else {
  throw new Error('Insufficient permissions');
}