Websites herunterladen, die Auth0 Lock nutzen

Über Auth0 Lock

Niemand will das Login-Fenster bauen. Registrierung, Passwort-Reset, Social Sign-in, Fehlerzustände, Barrierefreiheit, Übersetzungen: Die Arbeit ist unspektakulär, man macht dabei leicht subtile Fehler, und sie sieht bei jedem Produkt, das sie braucht, nahezu gleich aus. Auth0 Lock ist das Widget, das auf diese Unlust reagiert: ein fertiger Authentifizierungsdialog, den ein Entwickler in eine Seite einbettet und mit einem gehosteten Identitätsdienst verbindet. Das Widget erschien erstmals 2014, ist in JavaScript geschrieben und gehört zu einer Generation von Frontend-Komponenten, die Kontrolle gegen Zeitersparnis eingetauscht haben.

Spannend wird der Eintrag beim Anbieter. Bei uns ist das Widget dem Anbieter Okta zugeordnet, also nicht dem Unternehmen, das es ursprünglich entwickelt hat. Durch eine Übernahme ist die Identitätsplattform unter das Dach eines größeren Sicherheitsanbieters gewandert, und das eingebettete Widget kam mit. Jede Seite, die das Skript noch lädt, steht deshalb für eine Kundenbeziehung, die einen Eigentümerwechsel überstanden hat, und genau diesen Bestand will eine Analyse für den Enterprise-Vertrieb oder für Kundenabwanderung herausfiltern.

Den Rest der Geschichte erzählen die Versionsdaten. Im Einsatz haben wir 29 verschiedene Releases gesehen, und unsere Erkennung ordnet einen großen Teil der Websites der Version 10.8 zu. Eine so breite Streuung bei einem einzigen einbettbaren Widget ist für diese Art von Komponente normal, und genau deshalb lohnen sich die Daten. Ein Authentifizierungs-Widget wird in einer Seite oder einem Bundle festgepinnt, selten wieder angefasst und läuft weiter, lange nachdem das Team, das es eingebaut hat, zu einem anderen Muster übergegangen ist. Das Versionsfeld dient deshalb als Indikator dafür, wie lange es her ist, dass jemand das Frontend einer Website angefasst hat, und ob Korrekturen im Login-Pfad die Produktion erreicht haben.

Das Widget steht unter der Lizenz MIT, also kann es jeder lesen, forken und festpinnen. Den Identitätsdienst hinter dem Widget hostet allerdings niemand selbst. Ist das Skript vorhanden, lässt das auf ein Konto bei der Plattform schließen, auf eine dort eingerichtete Anwendung und auf ein Team, das entschieden hat, dass Identität kein Problem ist, das es selbst lösen muss. Ein solcher Schluss ist sicherer, als es die meisten Technologieerkennungen erlauben, denn ohne Konto hat das Widget niemanden, mit dem es sprechen könnte.

Einige Grenzen sollte man offen nennen. Die Erkennung sieht nur das eingebettete Widget, also taucht eine Website, die dieselbe Identitätsplattform über eine gehostete Anmeldeseite, ein mobiles SDK oder eine serverseitige Integration nutzt, hier überhaupt nicht auf. Die Zahl ist eine Untergrenze für die Plattform und nur für diese eine Integrationsart eine genaue Angabe. Stand Oktober 2026 erscheint die Signatur des Widgets auf 43 Websites.

Eine Abfrage pro Domain zeigt, ob ein einzelnes Unternehmen das Widget einbettet. Der Export klärt die Fragen, für die man den ganzen Bestand braucht: welche Branchen sich auf gehostete Identität festgelegt haben und welche ihre Lösung noch selbst bauen, wie sich die Versionsverteilung nach einem Sicherheitshinweis verschiebt, welche Konten Releases einsetzen, die alt genug für ein Supportgespräch sind, und auf welchen Websites das Widget neben Tools eines Wettbewerbers läuft. Für einen Anbieter von Authentifizierungslösungen, für Forscher, die den Update-Rückstand messen, und für alle, die den Markt für Identitätsprodukte für Entwickler abschätzen, ist die Liste die Analyseeinheit und nicht die einzelne Domain.