InhaltsverzeichnisKlicke auf den Link, um zur gewünschten Stelle zu navigieren
Dieser Inhalt wurde automatisch aus dem Ukrainischen übersetzt.
OAuth 1
OAuth 1 wurde Anfang der 2000er Jahre als Methode zur sicheren Zugriffsgewährung für Drittanbieteranwendungen auf die Ressourcen des Benutzers ohne Übertragung des Passworts entwickelt. Die Hauptidee war, dass ein Drittanbieterdienst im Namen des Benutzers Anfragen stellen konnte, aber jede Anfrage kryptografisch signiert wurde, um zu gewährleisten, dass sie unverändert und von einem autorisierten Client stammt.
Besonderheiten von OAuth 1:
- Kryptografische Signatur jeder Anfrage (HMAC-SHA1 oder RSA-SHA1).
- Verwendete zwei Arten von Tokens: Request-Token zur Einleitung der Autorisierung und Access-Token zum Zugriff auf Ressourcen.
- Konnte sogar ohne HTTPS funktionieren, da die Sicherheit durch die Signatur der Anfrage gewährleistet wurde.
- War hauptsächlich für serverseitige Anwendungen und eine begrenzte Anzahl von Autorisierungsszenarien geeignet.
OAuth 1 wurde aktiv in Diensten wie Twitter API v1 oder älteren Versionen von LinkedIn verwendet, wurde jedoch aufgrund der Komplexität bei der Implementierung und Problemen mit den Signaturen schrittweise durch OAuth 2 ersetzt.
OAuth 2
OAuth 2 erschien 2012 als vereinfachte, flexiblere und moderne Version des Protokolls zur Autorisierung und zum Zugriff auf Ressourcen. Sein Ziel ist es, die Arbeit der Entwickler zu erleichtern und verschiedenen Clienttypen (Web, mobile Anwendungen, SPA) den einfachen Zugriff auf die Ressourcen des Benutzers zu ermöglichen, ohne das Passwort zu übermitteln.
Besonderheiten von OAuth 2:
- Verwendet Zugriffstoken (Access Token) und optional Refresh Token. Access Token ist kurzfristig, Refresh Token ermöglicht die Verlängerung der Sitzung.
- Benötigt keine kryptografische Signatur der Anfrage - die Sicherheit wird über HTTPS gewährleistet.
- Unterstützt verschiedene Autorisierungsflüsse: Authorization Code (für serverseitige Web-Clients), Implicit (für SPA), Password (für vertrauenswürdige Clients) und Client Credentials (für Server-zu-Server-Interaktionen).
- Viel einfacher in der Implementierung und wird von modernen APIs (Google, Facebook, GitHub, Microsoft, Stripe usw.) unterstützt.
Wann was besser zu verwenden ist:
- OAuth 1: wenn Sie mit sehr alten APIs arbeiten, die es erfordern, oder in einer Umgebung ohne HTTPS, wo kryptografische Sicherheit auf Anfrageebene wichtig ist.
- OAuth 2: für moderne Web- und mobile Anwendungen, SPA, APIs, wo HTTPS garantiert ist. Auch praktisch für Drittanbieter-Clients, da es Refresh Tokens und verschiedene Autorisierungsflüsse unterstützt.
Vergleich von OAuth 1 und OAuth 2 in der Praxis
- Komplexität: OAuth 1 ist komplexer aufgrund der Signaturen, OAuth 2 ist einfacher und flexibler.
- Sicherheit: OAuth 1 ist sicher, auch ohne HTTPS, OAuth 2 benötigt HTTPS.
- Flexibilität: OAuth 1 ist eingeschränkt, OAuth 2 unterstützt viele Autorisierungsflüsse.
- Verwendung heute: OAuth 1 wird kaum noch verwendet, OAuth 2 ist der Standard für moderne APIs und Dienste.
OAuth 1 ging es um sichere Autorisierung ohne HTTPS, OAuth 2 um Flexibilität, Einfachheit und moderne Szenarien für Web- und mobile Anwendungen.
Dieser Beitrag hat noch keine Ergänzungen vom Autor.
