Authentifizierungsreihe (Teil 1): Anwendungsentwicklungspraktiken

Einführung

Die Identitäts-Authentifizierung spielt eine entscheidende Rolle beim Schutz des Datenzugriffs und der Privatsphäre der Nutzer in Internetanwendungen, insbesondere bei internen Anwendungen von Unternehmen. In dieser Artikelserie werden wir die Identitätsauthentifizierung aus verschiedenen Perspektiven betrachten, wobei wir uns in diesem Artikel speziell auf die Praxis der Identitätsauthentifizierung in der Anwendungsentwicklung konzentrieren.

In verschiedenen Anwendungen werden für die Identitätsauthentifizierung häufig die folgenden beiden Techniken verwendet:

1. Cookie & Session: Dieser traditionelle Authentifizierungsmechanismus wird häufig in Webanwendungen eingesetzt, hauptsächlich in Browsern. Er überprüft die Identität des Nutzers und verwaltet den Sitzungsstatus mithilfe von Cookies und Sessions.

2. Bearer Token: Dies ist ein modernerer Authentifizierungsmechanismus, der die Abhängigkeit von Browser-Cookies beseitigt und stattdessen das HTTP-Protokoll für die Authentifizierung nutzt. Er eignet sich besonders für API-Szenarien und kann in mobilen Anwendungen verwendet werden.

Unabhängig von der gewählten Methode müssen Entwickler den geeigneten Authentifizierungsansatz für ihre Produkte auswählen, um Datensicherheit, Nutzerdatenschutz und ein nahtloses Nutzererlebnis zu gewährleisten.

Traditionelle Webanwendungen

Früher haben wir Java JSP verwendet, um direkt Webanwendungen zu erstellen, wobei Nutzer mithilfe von JSESSIONID identifiziert wurden, einer Sitzungs-ID, die in einem Cookie im Browser des Clients gespeichert und bei jeder Anfrage mitgesendet wurde.

Dieser Ansatz hatte jedoch bestimmte Probleme. Da Cookies vom Browser auf dem Client-Gerät verwaltet und gespeichert werden, konnten böswillige Angreifer die gespeicherte Sitzungs-ID stehlen und den Nutzer imitieren, was ein Sicherheitsrisiko darstellte. Darüber hinaus hatten Entwickler manchmal Schwierigkeiten, angemessene Ablaufzeiten und Sicherheitsanforderungen für Cookies und Sessions festzulegen.

Bei der Entwicklung dieser Anwendungen mussten Entwickler häufig die Authentifizierung für jedes System separat implementieren, was unabhängig voneinander und mit unterschiedlichen Identitätssystemen geschah. Dies erforderte repetitive Arbeit. In solchen Fällen konnte Single Sign-On (SSO) diese Herausforderungen bewältigen, indem ein einheitliches Authentifizierungssystem verwendet wurde, das nur minimale Integrationsarbeit in jeder einzelnen Webanwendung erforderte, um die Authentifizierungsfunktionalität zu erreichen.

In den letzten Jahren haben sowohl Front-End- als auch Back-End-Technologien rasante Fortschritte gemacht. Entwickler sind dazu übergegangen, modernere Tech-Stacks zu verwenden, wodurch Anwendungen, die auf veralteten Technologien basieren, zu Legacy-Plattformen geworden sind. Es gibt jedoch Fälle, in denen neue Anforderungen an die Identitätssicherheit entstehen, aber die Änderung des alten Codes nicht möglich ist. In solchen Fällen kann ein alternativer Ansatz darin bestehen, Middleware als Reverse-Proxy zu verwenden, um die Authentifizierung durchzuführen. Bevor der Client die Anwendung erreicht, leitet die Middleware den Nutzer zu einer externen Authentifizierungsschnittstelle um, wo sich der Nutzer anmeldet. Die Middleware erhält dann die Identitätsinformationen des Nutzers und fügt sie der Anfrage hinzu, bevor sie an die alte Anwendung weitergeleitet wird. Dies ermöglicht es Entwicklern, neue Authentifizierungsmechanismen zu alten Anwendungen hinzuzufügen, ohne den bestehenden Code zu ändern.

Evolution von Webanwendungen: Trennung von Front-End und Back-End

Mit dem Aufkommen neuer Front-End-Technologien wie Vue und React haben sich die Webinteraktionen revolutioniert. Früher mussten Nutzer Formulare auf Webseiten ausfüllen und absenden, wobei sie mit dem Back-End über HTML-Formulare und Schaltflächen interagierten, was kein reibungsloses Nutzererlebnis bot. Heute sind Interaktionen auf der Seite in Echtzeit, und Entwickler verwenden JavaScript-Skripte, um mit Back-End-APIs zu interagieren, was ein konsistenteres und kontinuierlicheres Erlebnis bietet. Die Nutzerinteraktionen haben sich von direkten HTTP-Anfragen zum Aufruf verschiedener APIs verlagert.

Es gibt einige Unterschiede in den Identitätsauthentifizierungsmechanismen zwischen Webseiten-orientierten Anwendungen und API-orientierten Anwendungen. Während alte Cookies weiterhin verwendet werden können, sind sie für moderne Front-End-Technologien nicht geeignet. Neue Technologien ermöglichen es Entwicklern, ausdrucksstärkeren Code zu schreiben, wodurch sie mehr Operationen durchführen können, einschließlich Szenarien, in denen wir möglicherweise Nutzerkonten auf dem Front-End wechseln müssen. Die direkte Implementierung im Front-End über Cookies ist jedoch schwierig (aus Sicherheitsgründen werden Cookies, die mit der Nutzeridentität verbunden sind, oft als httpOnly konfiguriert, was verhindert, dass JavaScript-Skripte sie lesen und manipulieren können).

Typischerweise verwalten moderne Front-End-Anwendungen Nutzersitzungen selbst. Sobald sich ein Nutzer erfolgreich anmeldet, verwaltet das Front-End das vom Back-End generierte Token und fügt es dem Anfrageheader hinzu, wenn API-Aufrufe getätigt werden, damit das Back-End die Identität des Nutzers erkennen kann. APIs verwenden Tokens, um Nutzerinformationen zu identifizieren. Es stehen verschiedene technische Mittel zur Verfügung, wie z. B. die manuelle Implementierung von Token-Mechanismen mithilfe von JSON Web Tokens (JWT). Die JWT-Nutzlast speichert Identifikationsinformationen wie die Nutzer-ID, die dann signiert wird, damit das Back-End das Token überprüfen und die Nutzeridentitätsinformationen abrufen kann.

JWT hat jedoch auch einige Nachteile, wie z. B.:

• Die Ablaufzeit von JWT ist festgelegt und kann nach Abschluss der Signatur nicht geändert werden. Da es typischerweise nicht vom Back-End gespeichert wird und nur eine Signaturüberprüfung durchläuft, ist es nicht möglich, das Token zu widerrufen, was ein Risiko des Token-Diebstahls darstellt.

• Nutzlastdaten werden im Klartext gespeichert und können vom Client geparst werden, was sie für die Speicherung vertraulicher Informationen ungeeignet macht.

Glücklicherweise gibt es jetzt neue JWT-Spezifikationen, um diese Mängel zu beheben. Die JWT-Nutzlast kann ein Feld namens "jti" enthalten, um einen eindeutigen Bezeichner für das JWT zu speichern, der im Back-End-Cache gespeichert werden kann, um den Lebenszyklus des JWT zu steuern. Darüber hinaus definiert die JSON Web Encryption (JWE)-Spezifikation eine verschlüsselte JWT-Erweiterung, die die Vorteile asymmetrischer und symmetrischer Verschlüsselung kombiniert und sicherstellt, dass die Nutzlast in verschlüsselter Form übertragen wird, um ein Auslaufen zu verhindern.

Darüber hinaus gibt es andere JWT-basierte Technologien, die ausgereiftere Lösungen bieten, wie z. B. OpenID Connect. Es ist wichtig zu beachten, dass OpenID Connect nicht von JWT abhängt, aber sie können zusammen verwendet werden. OpenID Connect standardisiert die Mechanismen für Zugriffstokens und Aktualisierungstokens, wodurch Entwickler kurzfristige Tokens verwenden können, um das Risiko des Token-Diebstahls zu mindern. Das Ökosystem von OpenID Connect floriert ebenfalls, mit vielen Server- und Client-Implementierungen, die Entwicklern helfen, Identitätsauthentifizierungssysteme auf der Grundlage des OpenID Connect-Protokolls zu erstellen. Darüber hinaus können Open-Source-Identitätsauthentifizierungslösungen wie Keycloak Entwicklern helfen, sichere Identitätsauthentifizierungsdienste zu implementieren.

Neue Front-End-Technologiepraktiken, wie z. B. Next.js, führen schrittweise serverseitige Rendering-Techniken in den Front-End-Bereich ein. Dies stellt eine neue Entwicklung des alten Webentwicklungsparadigmas dar, das React mit Back-End-Programmen kombiniert, um das Nutzererlebnis weiter zu verbessern. Es gibt jetzt mehr Bibliotheken, wie NextAuth, die Entwicklern helfen können, die Identitätsauthentifizierung mit diesem Mechanismus zu implementieren, wodurch der Authentifizierungsprozess entwicklerfreundlicher wird.

API-Gateways und Identitätsauthentifizierung

Betrachten wir, wie unsere mobilen Anwendungen mit Daten interagieren. Verwenden sie auch APIs? In mobilen Anwendungen gibt es keinen Cookie-Mechanismus wie in Browsern, um Nutzersitzungen zu speichern, daher verwenden sie hauptsächlich Tokens, um Informationen über HTTP-Anfrageheader zu übermitteln.

Wie sieht es mit API-Diensten aus? Ein erfolgreiches Anwendungs-Back-End besteht typischerweise aus vielen komplexen API-Systemen, die einen einheitlichen Identitätsauthentifizierungsmechanismus erfordern. Andernfalls müssten Entwickler denselben Authentifizierungsmechanismus für jeden Dienst implementieren, was umständlich wäre.

API-Gateways können uns helfen, dieses Problem zu lösen, indem sie Authentifizierungs- und Parsing-Aufgaben ähnlich wie Cookies oder Tokens übernehmen und die geparsten Identitätsinformationen direkt an die Back-End-Dienste weiterleiten, wodurch redundante Arbeit reduziert wird. Apache APISIX und API7 Enterprise unterstützen auch die sofort einsatzbereite OpenID Connect-Authentifizierungsfunktionalität, die Nutzern hilft, Identitätsauthentifizierungsdienste direkt zu integrieren. Darüber hinaus unterstützen API-Gateways die Implementierung jedes Authentifizierungsmechanismus durch Skripting, sodass auch bei benutzerdefinierten Identitätsauthentifizierungsmechanismen diese in das API-Gateway integriert werden können, was die Anwendungsentwicklung vereinfacht.

Zusammenfassung

Die Entwicklung von Nutzerinteraktionsmethoden hat Fortschritte in der Identitätsauthentifizierung vorangetrieben. Der API-zentrierte Ansatz wird zu einem Mainstream-Trend, und APIs können von Microservice-Architekturen bereitgestellt werden, was einen einheitlichen Identitätsauthentifizierungsmechanismus erfordert, um redundante Entwicklung zu reduzieren. Daher sollten wir modernere Mechanismen wie OpenID Connect und JWT wählen, und die Verwendung eines API-Gateways kann zusätzliche Funktionalität für die API-Entwicklung bieten.