Bestimmen Sie Client-Typ und Akteur, wählen Sie einen unterstützten OAuth-Flow, fordern Sie den geringstmöglichen Berechtigungsumfang an, prüfen Sie Weiterleitungs-URI und Schutzparameter exakt, schützen und rotieren Sie Tokens und testen Sie den gesamten Lebenszyklus einschließlich Widerruf, Ablauf und Ausfall des Anbieters.
OAuth 2.0 ermöglicht einer Anwendung, eingeschränkten Zugriff auf eine API zu erhalten, ohne das Passwort des Nutzers zu übernehmen. Das Protokoll ist jedoch kein universeller „Anmelden“-Button. Das Design hängt vom Client-Typ ab, von der Anwesenheit eines Nutzers, von den Möglichkeiten, ein Secret sicher zu speichern, und davon, ob es sich um delegierten oder rein systemseitigen Zugriff handelt.
Fehler entstehen durch zu weit gefasste Berechtigungen, eine falsch validierte Weiterleitung, das Abfließen eines Tokens oder die Verwechslung von Authentifizierung und Autorisierung. Die Implementierung muss der Dokumentation des jeweiligen Anbieters und den aktuellen Sicherheitsempfehlungen folgen. Der folgende Rahmen hilft, die richtigen Fragen zu stellen, ersetzt jedoch keine Sicherheitsbewertung einer sensiblen Integration.
Unterscheiden Sie Akteur, Client und geschützte API
Skizzieren Sie zunächst, wer die Berechtigung erteilt, welche Anwendung sie anfordert und auf welche Ressource sie zugreift. Eine Web-App im Browser, eine serverseitige Anwendung, ein mobiler Client und eine Batch-Integration haben unterschiedliche Möglichkeiten, Geheimnisse zu schützen. Läuft ein Prozess ohne Nutzer, ist delegierter Zugriff möglicherweise nicht geeignet. Bestätigen Sie die Rollenbezeichnungen in der Dokumentation des Anbieters.
OAuth regelt die Delegation von Zugriffsrechten, nicht automatisch die Identität des Nutzers in jedem Kontext. Wenn Sie eine Anmeldung benötigen, verwenden Sie eine unterstützte Identitätsschicht und prüfen Sie deren Angaben korrekt. Die Berechtigung, ein Token zu erhalten, bedeutet zudem nicht das Recht, beliebige Aktionen auszuführen. Die API muss jede geschützte Ressource nach den aktuellen Regeln autorisieren.
Wählen Sie den unterstützten Flow nach den Fähigkeiten des Clients
Bei einer Nutzereinwilligung arbeitet man üblicherweise mit einer Weiterleitung über den Autorisierungsserver und einem kurzlebigen Code, den der Client sicher gegen ein Token austauscht. Ein öffentlicher Client benötigt einen Schutz, der berücksichtigt, dass er kein festes Geheimnis sicher aufbewahren kann. Die Server-zu-Server-Kommunikation zwischen vertrauenswürdigen Systemen kann einen anderen Flow ohne interaktiven Benutzer verwenden.
Wählen Sie den Flow nicht nach dem ersten Beispiel aus dem Internet. Prüfen Sie die Unterstützung beim Anbieter, den Anwendungstyp und die Bedrohungen der konkreten Umgebung. Ältere oder vereinfachte Verfahren können ungeeignete Eigenschaften haben. Dokumentieren Sie die Entscheidung zusammen mit Begründung, Bibliothek und Version, damit bei künftiger Wartung eine Änderung beurteilt werden kann.
- Anwesenheit des Nutzers und Art der Einwilligung
- Fähigkeit des Kunden, ein Geheimnis zu schützen
- erforderliche Art und Gültigkeitsdauer des Zugriffs
- aktuelle Unterstützung durch den jeweiligen Anbieter
Beschränken Sie Berechtigungsumfänge und Weiterleitungen
Fordern Sie nur die Berechtigungsumfänge an, die für eine bestimmte Funktion nötig sind. Eine Integration, die einen Kalender liest, muss nicht automatisch das Recht erhalten, Termine zu löschen. Erklären Sie Nutzern verständlich, warum der Zugriff erforderlich ist, und machen Sie die Grundfunktion nicht von einem optionalen Umfang abhängig. Fordern Sie bei einer Erweiterung der Funktionen eine neue Berechtigung bewusst an, nicht durch eine verdeckte Änderung.
Registrieren Sie Weiterleitungsadressen exakt und verwenden Sie keine offenen Platzhaltermuster ohne Grund. Überprüfen Sie bei der Rückkehr die Bindung an die begonnene Sitzung sowie die Schutzwerte entsprechend dem verwendeten Flow. Fehlermeldungen zeigen weder das Token noch interne Details an. Entfernen Sie nach erfolgreichem Abschluss die einmaligen Parameter aus der Adresse und leiten Sie zu einem sicheren Ziel weiter.
Schützen Sie Tokens während ihres gesamten Lebenszyklus
Behandeln Sie das Token als sensible Information mit einer bestimmten Zielgruppe, einem bestimmten Umfang und einer bestimmten Gültigkeitsdauer. Speichern Sie es nur dort, wo der jeweilige Teil der Anwendung es benötigt, und übertragen Sie es weder in URLs noch in Analysedaten oder gewöhnlichen Logs. Server-Secrets gehören in eine Secret-Verwaltung oder eine geschützte Konfiguration, nicht in das Repository oder das Redaktionssystem.
Entwerfen Sie die Erneuerung des kurzlebigen Zugriffs, die Rotation, den Widerruf und die Beendigung der Verbindung. Für ein Refresh-Token können strengere Anforderungen gelten als für ein Access-Token. Wird ein Nutzer oder eine Integration entfernt, widerrufen Sie die Berechtigung und löschen Sie auch die lokalen Daten gemäß den vereinbarten Regeln. Gleichzeitige Erneuerungen erfordern Koordination, damit sich Prozesse nicht gegenseitig den Status ungültig machen.
Testen Sie Fehler und überwachen Sie ohne Datenabfluss
Der Testsatz umfasst eine verweigerte Zustimmung, einen veränderten State, einen ungültigen Code, ein abgelaufenes Token, einen fehlenden Scope, einen Widerruf und einen nicht erreichbaren Autorisierungsserver. Prüfen Sie mehrere Konten und Organisationen, damit ein Token nicht dem falschen Mandanten zugeordnet wird. Verwenden Sie eine gepflegte Bibliothek, kontrollieren Sie jedoch deren Konfiguration und Updates.
Das Monitoring erfasst technische Ursachen von Fehlschlägen, die Anzahl der Token-Erneuerungen und ungewöhnliche Versuche, ohne die Tokens selbst zu speichern. Nutzer sollen eine sichere Möglichkeit erhalten, ihr Konto erneut zu verbinden. Das Betriebsteam muss eine Integration trennen und Zugangsdaten rotieren können, ohne andere Kunden zu beeinträchtigen. Das Incident-Verfahren umfasst auch die Prüfung des Umfangs eines möglichen Zugriffs.
- abgelehnte oder abgebrochene Nutzereinwilligung
- abgelaufenes, widerrufenes und fehlerhaft erneuertes Token
- unzureichender Berechtigungsumfang für die angeforderte Operation
- sichere Kontotrennung und Bereinigung der Sitzung
Häufige Fragen
Ist OAuth 2.0 eine Anmeldung?
OAuth 2.0 ist ein Framework für delegierten Zugriff. Die Anmeldung von Nutzern erfordert eine Identitätsschicht und eine korrekte Prüfung der Daten nach einem unterstützten Standard. Ein Access Token allein kann ohne Kontext nicht als Identitätsprofil betrachtet werden.
Darf ein Token im Browser gespeichert werden?
Das hängt von der Architektur und den Bedrohungen ab. Ein öffentlicher Client kann ein festes Geheimnis nicht so schützen wie ein Server. Der Entwurf minimiert die Exposition und richtet sich nach den aktuellen Vorgehensweisen der verwendeten Plattform und des Anbieters.
Warum reicht ein einziger breiter Berechtigungsumfang nicht aus?
Eine weitreichende Berechtigung vergrößert die Folgen eines Datenlecks oder Fehlers und erschwert es dem Nutzer, die Einwilligung zu verstehen. Jede Funktion sollte den kleinsten Umfang nutzen, den sie für ihre konkrete Aufgabe benötigt.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
