Einführung
Die tokenbasierte Authentifizierung ist heutzutage überall im Web prominent. Da die meisten Webunternehmen eine API verwenden, sind Token der beste Weg, um die Authentifizierung für mehrere Benutzer zu handhaben.
Bei der Auswahl der tokenbasierten Authentifizierung für Ihre Anwendung gibt es einige sehr wichtige Faktoren. Die Hauptgründe für Token sind:
- Zustandslose und skalierbare Server
- Bereit für mobile Anwendungen
- Authentifizierung an andere Anwendungen weitergeben
- Zusätzliche Sicherheit
Wer verwendet tokenbasierte Authentifizierung?
Jede wichtige API oder Webanwendung, auf die Sie gestoßen sind, hat höchstwahrscheinlich Token verwendet. Anwendungen wie Facebook, Twitter, Google+, GitHub und viele mehr verwenden Token.
Schauen wir uns genau an, wie es funktioniert.
Warum Token entstanden sind
Bevor wir sehen können, wie die tokenbasierte Authentifizierung funktioniert und welche Vorteile sie bietet, müssen wir uns ansehen, wie die Authentifizierung in der Vergangenheit durchgeführt wurde.
Serverbasierte Authentifizierung (die traditionelle Methode)
Da das HTTP-Protokoll zustandslos ist, bedeutet dies, dass unsere Anwendung bei der nächsten Anforderung nicht weiß, wer wir sind, wenn wir einen Benutzer mit einem Benutzernamen und einem Kennwort authentifizieren. Wir müssten uns erneut authentifizieren.
Die traditionelle Art, unsere Anwendungen daran zu erinnern, wer wir sind, besteht darin, die angemeldeten Benutzerinformationen auf dem Server zu speichern. Dies kann auf verschiedene Arten in der Sitzung erfolgen, normalerweise im Speicher oder auf der Festplatte.
Da das Web, die Anwendungen und der Aufstieg der mobilen Anwendung entstanden sind, hat diese Authentifizierungsmethode Probleme gezeigt, insbesondere bei der Skalierbarkeit.
Die Probleme mit der serverbasierten Authentifizierung
Bei dieser Authentifizierungsmethode traten einige größere Probleme auf.
- Sitzungen: Jedes Mal, wenn ein Benutzer authentifiziert wird, muss der Server irgendwo auf unserem Server einen Datensatz erstellen. Dies geschieht normalerweise im Arbeitsspeicher, und wenn sich viele Benutzer authentifizieren, erhöht sich der Overhead auf Ihrem Server.
- Skalierbarkeit: Da Sitzungen im Arbeitsspeicher gespeichert werden, führt dies zu Problemen mit der Skalierbarkeit. Wenn unsere Cloud-Anbieter damit beginnen, Server zu replizieren, um die Anwendungslast zu bewältigen, werden wichtige Informationen im Sitzungsspeicher unsere Skalierbarkeit einschränken.
- KORS: Da wir unsere Anwendung so erweitern möchten, dass unsere Daten auf mehreren Mobilgeräten verwendet werden können, müssen wir uns Gedanken über die gemeinsame Nutzung von Cross-Origin-Ressourcen (CORS) machen. Wenn Sie AJAX-Aufrufe verwenden, um Ressourcen von einer anderen Domäne abzurufen (mobil für unseren API-Server), können Probleme mit verbotenen Anforderungen auftreten.
- CSRF: Wir werden auch Schutz vor Cross-Site Request Forgery (CSRF) haben. Benutzer sind anfällig für CSRF-Angriffe, da sie bereits bei einer Bankwebsite authentifiziert werden können und dies beim Besuch anderer Websites ausgenutzt werden kann.
Bei diesen Problemen, bei denen die Skalierbarkeit das Hauptproblem darstellt, war es sinnvoll, einen anderen Ansatz zu versuchen.
Funktionsweise der tokenbasierten Authentifizierung
Die tokenbasierte Authentifizierung ist zustandslos. Wir speichern keine Informationen über unseren Benutzer auf dem Server oder in einer Sitzung.
Dieses Konzept allein löst viele der Probleme beim Speichern von Informationen auf dem Server.
Keine Sitzungsinformationen bedeuten, dass Ihre Anwendung nach Bedarf skalieren und weitere Maschinen hinzufügen kann, ohne sich Gedanken darüber machen zu müssen, wo ein Benutzer angemeldet ist.
Obwohl diese Implementierung variieren kann, lautet der Kern wie folgt:
- Benutzer fordert Zugriff mit Benutzername / Passwort an
- Anwendung überprüft Anmeldeinformationen
- Anwendung stellt dem Client ein signiertes Token zur Verfügung
- Der Client speichert dieses Token und sendet es zusammen mit jeder Anforderung
- Der Server überprüft das Token und antwortet mit Daten
Jede einzelne Anforderung erfordert das Token. Dieses Token sollte im HTTP-Header gesendet werden, damit wir bei der Idee zustandsloser HTTP-Anforderungen bleiben. Wir müssen unseren Server auch so einstellen, dass er Anfragen von allen Domänen mit Access-Control-Allow-Origin: * akzeptiert. Das Interessante an der Bezeichnung von * im ACAO-Header ist, dass Anforderungen zur Angabe von Anmeldeinformationen wie HTTP-Authentifizierung, clientseitigen SSL-Zertifikaten oder Cookies nicht zulässig sind.
Sobald wir uns mit unseren Informationen authentifiziert haben und unser Token haben, können wir mit diesem Token viele Dinge tun.
Wir könnten sogar ein berechtigungsbasiertes Token erstellen und dieses an eine Drittanbieteranwendung weitergeben (z. B. eine neue mobile App, die wir verwenden möchten), und sie können auf unsere Daten zugreifen – jedoch nur auf die Informationen, die wir mit diesem bestimmten Token zugelassen haben.
Die Vorteile von Token
Zustandslos und skalierbar
Token werden clientseitig gespeichert. Völlig zustandslos und bereit, skaliert zu werden. Unsere Load Balancer können einen Benutzer an einen unserer Server weitergeben, da nirgendwo Status- oder Sitzungsinformationen vorhanden sind.
Wenn wir Sitzungsinformationen über einen angemeldeten Benutzer speichern würden, müssten wir diesen Benutzer weiterhin an denselben Server senden, auf dem er sich angemeldet hat (Sitzungsaffinität genannt).
Dies bringt Probleme mit sich, da einige Benutzer auf denselben Server gezwungen wären und dies zu starkem Datenverkehr führen könnte.
Keine Sorge! Diese Probleme sind mit Token verschwunden, da das Token selbst die Daten für diesen Benutzer enthält.
Sicherheit
Das Token, kein Cookie, wird bei jeder Anfrage gesendet und da kein Cookie gesendet wird, hilft dies, CSRF-Angriffe zu verhindern. Selbst wenn Ihre spezifische Implementierung das Token clientseitig in einem Cookie speichert, handelt es sich bei dem Cookie lediglich um einen Speichermechanismus anstelle eines Authentifizierungsmechanismus. Es gibt keine sitzungsbasierten Informationen zu manipulieren, da wir keine Sitzung haben!
Das Token läuft auch nach einer festgelegten Zeit ab, sodass sich ein Benutzer erneut anmelden muss. Dies hilft uns, sicher zu bleiben. Es gibt auch das Konzept des Token-Widerrufs, mit dem wir ein bestimmtes Token und sogar eine Gruppe von Token basierend auf derselben Autorisierungserteilung ungültig machen können.
Erweiterbarkeit (Freund eines Freundes und Berechtigungen)
Token ermöglichen es uns, Anwendungen zu erstellen, die Berechtigungen mit anderen teilen. Zum Beispiel haben wir zufällige soziale Konten mit unseren wichtigsten wie Facebook oder Twitter verknüpft.
Wenn wir uns über einen Dienst bei Twitter anmelden (sagen wir Buffer), erlauben wir Buffer, in unserem Twitter-Stream zu posten.
Durch die Verwendung von Token stellen wir auf diese Weise selektive Berechtigungen für Anwendungen von Drittanbietern bereit. Wir könnten sogar unsere eigene API erstellen und spezielle Berechtigungstoken verteilen, wenn unsere Benutzer einer anderen Anwendung Zugriff auf ihre Daten gewähren möchten.
Mehrere Plattformen und Domains
Wir haben vorhin ein wenig über CORS gesprochen. Wenn unsere Anwendung und unser Service erweitert werden, müssen wir den Zugriff auf alle Arten von Geräten und Anwendungen bereitstellen (da unsere App auf jeden Fall populär werden wird!).
Da unsere API nur Daten bereitstellt, können wir auch die Designauswahl für die Bereitstellung von Assets aus einem CDN treffen. Dadurch werden die Probleme beseitigt, die CORS aufwirft, nachdem wir eine schnelle Header-Konfiguration für unsere Anwendung festgelegt haben.
Access-Control-Allow-Origin: *Unsere Daten und Ressourcen sind jetzt für Anfragen von jeder Domain verfügbar, solange ein Benutzer über ein gültiges Token verfügt.
Standardbasiert
Beim Erstellen des Tokens haben Sie einige Optionen. Wir werden mehr in dieses Thema eintauchen, wenn wir eine API in einem Folgeartikel sichern, aber der zu verwendende Standard wären JSON-Webtoken.
Dieses praktische Debugger- und Bibliotheksdiagramm zeigt die Unterstützung für JSON-Webtoken. Sie können sehen, dass es eine große Menge an Unterstützung in einer Vielzahl von Sprachen hat. Dies bedeutet, dass Sie Ihren Authentifizierungsmechanismus tatsächlich ausschalten können, wenn Sie dies in Zukunft tun möchten!
Fazit
Dies war nur ein Blick auf das Wie und Warum der tokenbasierten Authentifizierung. Wie immer in der Welt der Sicherheit gibt es zu jedem Thema viel mehr und es variiert je nach Anwendungsfall. Wir haben uns sogar mit einigen Themen zur Skalierbarkeit befasst, die ebenfalls ein eigenes Gespräch verdienen.
Dies war ein kurzer Überblick auf hoher Ebene, also zögern Sie nicht, auf alles hinzuweisen, was Sie verpasst haben, oder auf Fragen, die Sie zu diesem Thema haben.
In unserem nächsten Artikel werden wir uns mit der Anatomie von JSON-Webtoken befassen.
Hinweis: Hinzufügen von ACAO-Header-Informationen und CSRF-Klarstellungen (danke an Emily Stark für die Artikelinformationen)