How to Improve Your OAuth Developer Experience

Developer Experience (DX) ist heutzutage ein häufig verwendeter, aber oft missverstandener Begriff. Die Wahrheit ist, dass ein schlechtes Entwickler-Setup die Time-to-Market Ihrer digitalen Dienste negativ beeinflussen kann. Gerade bei der Implementierung von Sicherheitslösungen kann DX leiden, wenn ein suboptimales technisches Design gewählt wird, was leider keine Seltenheit ist.

Typischerweise sichern Unternehmen ihre Apps mit der OAuth-Spezifikationsfamilie. Die anspruchsvolle Sicherheitsarbeit wird dann an ein Identitäts- und Zugriffsverwaltungssystem (IAM) eines Drittanbieters ausgelagert. Sie stellen eine Komponente namens Autorisierungsserver bereit, mit der sowohl Ihre UIs als auch Ihre APIs interagieren, um schwierige Sicherheitsbereiche auszulagern. Um dies sicher umzusetzen, ist auch eine gute technische Anleitung Ihres IAM-Anbieters erforderlich.

Im Kern ist OAuth ein einfaches und elegantes Framework, das auf einer Trennung von Bedenken basiert. Es kann auch entwicklerfreundlich sein, wenn es richtig verwendet wird. Bei der Implementierung von Sicherheitslösungen muss ein Unternehmen sorgfältig und sorgfältig darauf achten, zunächst die Anforderungen zu identifizieren und dann Designs und Sicherheitskomponenten auszuwählen, die diese erfüllen. Geschieht dies nicht, kann dies manchmal ernsthafte Auswirkungen auf die Geschäftsergebnisse haben.

In diesem Artikel werde ich einige Empfehlungen zur Verbesserung der OAuth-Entwicklererfahrung geben und es Entwicklern ermöglichen, geschäftsorientierter zu arbeiten. Dies wird aus der Perspektive von Web- und API-Entwicklern betrachtet. Ich werde auch einige Entwurfsmuster hervorheben, die es Ihrem Unternehmen ermöglichen, überall die beste Sicherheit auszuführen, auch auf Entwickler-Workstations.

Single-Page-Anwendungen

Viele Unternehmen entscheiden sich dafür, Single-Page-Anwendungen (SPAs) zu erstellen, um eine schnelle und interaktive Benutzererfahrung zu ermöglichen. Sowohl aus DX- als auch aus geschäftlicher Sicht ist diese Lösung sehr gut aufeinander abgestimmt. Der Entwickler verwendet eine moderne produktive Technologie, um die Benutzeroberfläche zu erstellen, und alle Bemühungen konzentrieren sich auf eine großartige Benutzererfahrung. Beim Erstellen von SPAs ist es üblich, eine anfängliche Sicherheitslösung mit den folgenden Teilen zu erstellen.

Ein Problem bei diesem App-Design ist seine Sicherheit, da es Token im Browser verwendet und wahrscheinlich ein Aktualisierungstoken im lokalen Speicher speichert. Dies folgt nicht den Best Practices von OAuth für browserbasierte Apps und wird wahrscheinlich während Penetrationstests von Sicherheitsbeteiligten als Problem angesprochen. Stattdessen wird empfohlen, einen Cookie-Layer auf Anwendungsebene für die SPA bereitzustellen.

In einigen Unternehmen können Architekten die Cookie-basierte Anforderung an Webentwickler werfen. Um dies jedoch mit hochwertigem DX zu lösen, ist API-Denken erforderlich, und Webentwickler sind nicht immer die besten, um diese Anforderung zu entwerfen. Der Entwickler kann zuerst online suchen und dann eine erste Lösung implementieren, die einen Reverse-Proxy oder ein API-Gateway und eine Plugin-Komponente verwendet, die OpenID Connect (OIDC) implementiert.

Der Entwickler wird dann oft auf mehrere Pain Points stoßen. Erstens ist das OIDC-Plugin möglicherweise nur für Websites konzipiert und unterstützt die Weiterleitung von Jason Web Tokens (JWTs) an APIs nicht. Zweitens kann es schlecht mit dem Ablauf umgehen, da es beispielsweise keine Unterstützung für das Aktualisieren zugrunde liegender Zugriffstoken gibt. Schließlich ist es unwahrscheinlich, dass es SPA- oder Ajax-freundlich ist und kann abrupte 302-Weiterleitungen auf Ajax-Antworten ausgeben, was nicht das richtige Verhalten für ein SPA ist.

Schließlich wird der Entwickler erkennen, dass ein Backend für Frontend (BFF) erforderlich ist, um die oben genannten Bedenken auf SPA-freundliche Weise korrekt zu behandeln. Der Entwickler muss dann eine Cookie-Ausgabetechnologie auswählen. Oft stimmt diese Auswahl mit den Websites des Unternehmens überein, die in einer Sprache wie C# codiert sein könnten. Dies kann zu einem dicken Backend auf einer Entwickler-Workstation führen.

Die SPA implementiert ihre Sicherheit jetzt korrekt, aber diese Änderung hat sich auf die DX ausgewirkt. Um statische Webinhalte für die React-App zu erhalten und damit Cookies funktionieren, muss sich der React-Entwickler jetzt mit vielen Backend-Sicherheitsbedenken für alle zukünftigen Entwicklungen auseinandersetzen. In einigen Fällen kann es einige Zeit dauern, bis der Entwickler den Ablauf, die Fehlerbehandlung und die Benutzerfreundlichkeit zuverlässig zum Laufen gebracht hat.

Es ist jedoch möglich, eine moderne Form des Backend-für-Frontend-Musters zu verwenden, um DX zu optimieren. Diese Strategie beinhaltet die Trennung der BFF-Bedenken von der Bereitstellung statischer Inhalte. Die BFF wird dann in einer API-Domäne bereitgestellt, die dieselbe übergeordnete Domäne wie der Webursprung der SPA teilen muss, damit Cookies Erstanbieter bleiben. Der React-Entwickler muss dann nur noch React-Code für alle zukünftigen Entwicklungen schreiben.

Dies wird als Token-Handler-Muster bezeichnet, bei dem der OAuth-Agent mit dem Autorisierungsserver interagiert und dann Cookies im Namen der SPA ausgibt. Der OAuth-Proxy stellt sicher, dass API-Anfragen SPA-freundlich verwaltet werden, übersetzt Cookies in Tokens und wendet auch generische Sicherheitsprüfungen an. Um die Token-Handler-Komponenten zu integrieren, müssen Sie nur getestete Implementierungen des OAuth-Agenten und des OAuth-Proxys konfigurieren und bereitstellen.

Dieses Entwurfsmuster trennt Web- und API-Belange, um die beste Auswahl zu bieten. Es ist weiterhin möglich, den OAuth-Agent und den OAuth-Proxy für die Webdomäne bereitzustellen, wenn dies zu Ihrer Webarchitektur passt. Ein Multidomain-Setup bietet jedoch wahrscheinlich die bestmögliche SPA-Entwicklererfahrung.

Zero-Trust-APIs

DX muss auch für Backend-Entwickler und -Tester aktiviert werden, was Einblicke erfordern kann, wenn Sicherheit verwendet wird. Betrachten Sie den folgenden mobilen und API-End-to-End-Flow, bei dem Multifaktor-Authentifizierung (MFA) verwendet wird, einschließlich zeitbasierter Einmalkennwörter (TOTP), die von der Google Authenticator-App auf einem Mobilgerät empfangen werden.

Das Phantom-Token-Muster wird auch verwendet, um an die mobile App gelieferte Token vertraulich zu halten. Die APIs verfolgen einen Zero-Trust-Ansatz, bei dem JWT-Zugriffstoken zwischen APIs weitergeleitet werden und jede API das JWT bei jeder Anfrage digital verifiziert.

All dies ist aus Sicherheitssicht in Ordnung, aber bedenken Sie, wie sich dies auf den Entwickler der einzelnen Microservices auswirkt. Um ein Zugriffstoken auf Benutzerebene zum Testen zu erhalten, muss der Entwickler standardmäßig einen Codefluss ausführen und dann zur mobilen App wechseln und den zweiten Faktor eingeben. Dies ist kein produktives Setup.

Um dieses Problem zu lösen, müssen Sie zunächst den grundlegenden OAuth-Fluss für eine gesicherte API verstehen. Das JWT-Zugriffstoken stellt einen Vertrag für die API bereit. Zuerst wird seine digitale Signatur unter Verwendung eines asymmetrischen öffentlichen Schlüssels verifiziert. Als nächstes werden seine Ansprüche für die Autorisierung verwendet. Eine JWT-Bibliothek wird auch zum Zwischenspeichern der öffentlichen Schlüssel zum Signieren von Token verwendet, um eine gute Leistung sicherzustellen.

Integrationstests für die Bestell-API simulieren normalerweise den Aufruf der Upstream-Kunden-API. Sie können die schwierige OAuth-bezogene Infrastruktur mit demselben Ansatz umgehen, solange Sie denselben JWT-Zugriffstokenvertrag bereitstellen. Die Bestell-API muss nicht testen, ob die Authentifizierung funktioniert. Stattdessen kann es einfach einen HTTP-Endpunkt eines Dienstprogramms nach einem Token für einen bestimmten Benutzer fragen. Dieser Endpunkt generiert sein eigenes Schlüsselpaar, gibt JWTs mit dem privaten Schlüssel aus und stellt den öffentlichen Schlüssel der API zur Verfügung.

Der Sicherheitscode in der API ist unverändert und verhält sich in bereitgestellten Umgebungen, in denen die API mit einem echten Autorisierungsserver verbunden ist, identisch. Dennoch bietet das lokale Setup-Design eine gute DX für Entwickler von gesicherten APIs und ermöglicht ihnen auch, sicher zu entwickeln. Das Mocking des JSON Web Key Set (JWKS)-Endpunkts des Autorisierungsservers kann entweder über eine Utility-API oder ein HTTP-Tool wie WireMock erfolgen.

Backend-Infrastruktur für beste Entwicklererfahrung

Die Geschichte der API-Entwickler endet nicht mit dem Schreiben und Testen von API-Code. Es gibt eine Reihe weiterer Komponenten, die Entwickler verwenden und erweitern werden. Die folgenden Komponenten sind besonders relevant, um eine hochwertige End-to-End-DX während der gesamten OAuth-Entwicklung zu ermöglichen.

Sowohl das API-Gateway als auch der Autorisierungsserver sind kritische Teile Ihrer Architektur und benötigen eine gute Erweiterbarkeit, um über Plugins und Skripting verwaltet zu werden. Bei der Implementierung dieser Art von Aufgabe führen Backend-Entwickler lokal ein komplexeres Setup mit mehreren Komponenten aus. Es kann erhebliche Produktivitätsvorteile geben, wenn Entwickler sie alle lokal bereitstellen können. Auf diese Weise kann die End-to-End-Zuverlässigkeit so früh wie möglich in Ihrer Bereitstellungspipeline überprüft werden, wonach das gleiche Verhalten einfach auf andere Umgebungen übertragen wird.

Cloud-native Komponenten, die überall bereitgestellt werden können, einschließlich Entwickler-Workstations, passen am besten zu diesem Modell. Mit diesem Ansatz können Sie die besten Komponenten mit der erforderlichen Erweiterbarkeit auswählen. Unter den Platform-as-a-Service (PaaS)-Komponenten finden Sie möglicherweise weniger Auswahlmöglichkeiten und in einigen Bereichen können Blockierungsprobleme auftreten, die sich sowohl auf DX als auch auf das Geschäft auswirken können.

Wenn Sie Kubernetes verwenden, kann ein kostenloser, leichtgewichtiger Ingress-Controller als API-Gateway verwendet werden, und Sie sollten einen mit guter Unterstützung für Plugins wählen. Ebenso können Sie ein hochmodernes Protokollierungssystem wie den Elastic Stack kostenlos ausführen. Sie könnten dann auch einen Cloud-nativen Autorisierungsserver verwenden, z. B. die kostenlose Community-Edition des Curity Identity Server.

Schnelle Lösung von Vorfällen

Ein zentraler DX-Bereich ist Ihr technischer Supportprozess, sowohl während als auch nach der Codierung. Entwickler müssen möglicherweise auf Abruf bereitstehen, um Kunden bei Produktionsproblemen zu unterstützen. In einigen Szenarien sind Organisationen möglicherweise nicht ausreichend vorbereitet, was für Entwickler stressig sein und zu Ihren erfahrensten Ingenieuren eskalieren kann, was sich auf zukünftige Geschäftsergebnisse auswirkt.

Die OAuth-Sicherheit umfasst mehr bewegliche Teile als ältere eigenständige Systeme. Ihre Entwickler müssen verstehen, wie sie OAuth-Probleme während der Codierung beheben und Ablauf- und Fehlerbedingungen proben. Aus DX-Sicht funktioniert das folgende Setup am besten, da es jedem Entwickler oder Tester ermöglicht, Protokolle für jede Komponente abzufragen. Dies reduziert die „Analysezeit“ und kann Ausfallzeiten während solcher Ereignisse minimieren.

Wenn Sie den oben genannten Ablauf des technischen Supports aktivieren können, werden Probleme beim Codieren genauso behandelt wie in der Produktion, was dazu beiträgt, den Stress zu verringern. Wenn also DevOps-Mitarbeiter Produktionsvorfälle beheben, benötigen sie weniger Entwicklereingaben. Im Laufe der Zeit wird dieser abgestimmte Personalprozess mehr Probleme frühzeitig finden und sowohl DX als auch Qualität verbessern. Machen Sie außerdem die Protokollqualität zu einem Teil Ihrer Auswahlkriterien für Komponenten von Drittanbietern, die für Ihr Backend unerlässlich sind.

Bereitstellung eines guten Ökosystems für Entwickler

Bei DX geht es darum, das beste Ökosystem für Entwickler bereitzustellen, um die geschäftliche Agilität zu verbessern. Stellen Sie für schwierige Bereiche wie Bereitstellung, Sicherheit und Lösung von Vorfällen sicher, dass die von Ihnen gewählten Optionen auch auf lokalen Arbeitsstationen gut funktionieren und Ihre Geschäftsanforderungen erfüllen. Sie werden dann sichere und zuverlässige Software mit einfacherem Code erstellen.

Es ist auch ein schrittweiser Weg, und technische Ziele müssen gegen geschäftliche Prioritäten abgewogen werden. Es sollte möglich sein, alle DX-Ziele in Bezug auf ihren Geschäftswert zu artikulieren, sei es eine schnellere Webentwicklung, besserer Datenschutz oder weniger Vorfälle. Dies hilft Ihnen, Unterstützung für technische Initiativen zu gewinnen und diese schrittweise im Rahmen einer technischen Roadmap umzusetzen.

Wir bei Curity sind uns der Bedeutung von DX für Ihr Unternehmen bewusst. Wir verbessern daher kontinuierlich unsere Entwicklerressourcen, einschließlich Leitfäden für die Web-, Mobil- und API-Entwicklung. Die OAuth-Spezifikationsfamilie ermöglicht es Ihnen, viele Sicherheitslösungen zu implementieren, und wir stellen auch sicher, dass unsere erweiterten Optionen durchgängig auf einem Entwicklungscomputer ausgeführt werden können.