Zwei-Faktor-Authentifizierung im Magento Adminbereich einrichten

1. Warum Zwei-Faktor-Authentifizierung im Adminbereich Pflicht ist

Der Magento Adminbereich ist die zentrale Angriffsfläche jedes Shops: Von hier aus lassen sich Zahlungsmethoden konfigurieren, Admin-Nutzer anlegen, Layout-XML und sogar ausführbarer Code über Custom-Module einschleusen. Ein einzelnes Passwort als einziger Schutzfaktor ist angesichts von Credential-Stuffing, Phishing-Kampagnen und wiederverwendeten Passwörtern aus anderen Datenlecks kein ausreichendes Sicherheitsniveau mehr. Genau hier setzt Zwei-Faktor-Authentifizierung an: Selbst wenn ein Angreifer das Admin-Passwort kennt, verhindert der zweite Faktor, sei es ein TOTP-Code, ein Hardware-Token oder eine Push-Benachrichtigung, den unautorisierten Login.

Seit Magento 2.3.7 ist das Modul Magento_TwoFactorAuth Bestandteil beider Editionen, Open Source und Adobe Commerce. Seit Magento 2.4.x ist Zwei-Faktor-Authentifizierung in Adobe Commerce standardmäßig aktiviert und kann nicht mehr folgenlos deaktiviert werden, während sie in Magento Open Source weiterhin optional, aber dringend empfohlen bleibt. In der Version 2.4.8-p4, die dieser Beitrag als Referenz verwendet, ist die Provider-Architektur vollständig auf Service Contracts umgestellt, was eigene Erweiterungen deutlich sauberer macht als in den frühen 2.3er-Releases. Wer Zwei-Faktor-Authentifizierung heute noch als optionales Feature behandelt, ignoriert eine der wirksamsten und zugleich am einfachsten umsetzbaren Sicherheitsmaßnahmen für den Adminbereich.

Wichtig für die Einordnung: Zwei-Faktor-Authentifizierung schützt ausschließlich den interaktiven Admin-Login über das Backend-UI. Sie ersetzt keine anderen Sicherheitsmaßnahmen wie IP-Whitelisting, Rollen- und Rechteverwaltung über ACL oder regelmäßige Passwort-Rotation, sondern ergänzt sie um eine zusätzliche Verteidigungsebene. In Kombination mit einer restriktiven Rollenverwaltung und einer sauber gepflegten ACL-Struktur bildet Zwei-Faktor-Authentifizierung das Fundament einer belastbaren Admin-Absicherung.

2. Magento_TwoFactorAuth über system.xml konfigurieren

Die Konfiguration von Magento_TwoFactorAuth erfolgt über den Konfigurationsbereich Stores > Configuration > Security > 2FA, der im Modul über eine eigene system.xml-Sektion mit dem Bezeichner twofactorauth definiert wird. Diese Sektion ist ausschließlich auf Website- oder Store-View-Ebene deaktiviert und greift nur auf Default-Scope, weil Zwei-Faktor-Authentifizierung eine Eigenschaft des Adminbereichs ist und nicht pro Storefront-Ansicht variieren darf. Innerhalb der Sektion werden pro Provider ein eigener Aktivierungsschalter sowie providerspezifische Zusatzfelder wie API-Schlüssel für Duo Security oder die Anwendungs-ID für U2F bereitgestellt.

Die zentrale Einstellung force_providers bestimmt, welche Provider für alle Admin-Benutzer erzwungen werden. Wird hier google für Google Authenticator eingetragen, muss sich jeder Admin-Benutzer beim nächsten Login mit TOTP registrieren, bevor der Zugriff auf das Backend gewährt wird. Mehrere Provider lassen sich kommagetrennt kombinieren, sodass Benutzer aus einer Auswahl wählen können, etwa TOTP oder U2F/WebAuthn parallel. Die Konfiguration lässt sich vollständig über app/etc/config.php exportieren und versionieren, was in Deployment-Pipelines Pflicht sein sollte, damit die 2FA-Konfiguration nicht versehentlich zwischen Umgebungen abweicht.

<!-- app/code/Mironsoft/Security/etc/adminhtml/system.xml -->
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Config:etc/system_file.xsd">
    <system>
        <section id="twofactorauth" translate="label" type="text"
                 sortOrder="20" showInDefault="1" showInWebsite="0" showInStore="0">
            <label>Two-Factor Authentication</label>
            <tab>security</tab>
            <resource>Magento_TwoFactorAuth::config</resource>
            <group id="general" translate="label" type="text"
                   sortOrder="10" showInDefault="1" showInWebsite="0" showInStore="0">
                <label>General</label>
                <field id="force_providers" translate="label comment" type="multiselect"
                       sortOrder="10" showInDefault="1" showInWebsite="0" showInStore="0">
                    <label>Force Providers</label>
                    <comment>Erzwungene Provider gelten fuer alle Admin-Benutzer ohne Ausnahme.</comment>
                    <source_model>Magento\TwoFactorAuth\Model\Config\Source\Providers</source_model>
                </field>
            </group>
            <group id="u2f" translate="label" type="text"
                   sortOrder="30" showInDefault="1" showInWebsite="0" showInStore="0">
                <label>U2F / WebAuthn</label>
                <field id="relying_party_id" translate="label comment" type="text"
                       sortOrder="10" showInDefault="1" showInWebsite="0" showInStore="0">
                    <label>Relying Party ID</label>
                    <comment>Muss exakt der Domain des Adminbereichs entsprechen, sonst schlaegt der Origin-Check fehl.</comment>
                </field>
            </group>
        </section>
    </system>
</config>

Zusätzlich zur globalen Konfiguration bietet Magento_TwoFactorAuth eine ACL-Ressource pro Provider, sodass sich Zwei-Faktor-Authentifizierung theoretisch auch auf Basis von Benutzerrollen differenziert steuern lässt, auch wenn die vollständige Enforcement-Logik pro Rolle in der Community-Version eingeschränkter ist als in Adobe Commerce mit Magento_AdminAdobeIms. Wer präzisere Kontrolle über einzelne Rollen benötigt, kombiniert die Standardkonfiguration mit einem eigenen Plugin auf AuthenticationInterface, das die Rolle des einloggenden Benutzers prüft und den Provider-Zwang dynamisch anpasst.

3. Provider im Überblick: TOTP, Duo, U2F/WebAuthn, Authy

Magento_TwoFactorAuth liefert von Haus aus vier Provider-Implementierungen, die jeweils eine eigene Klasse implementieren, welche das Interface Magento\TwoFactorAuth\Api\ProviderInterface erfüllt. Der Provider Google Authenticator, intern als google referenziert, implementiert den TOTP-Standard nach RFC 6238 und funktioniert mit jeder kompatiblen Authenticator-App wie Google Authenticator, Microsoft Authenticator oder Authy im TOTP-Modus. Der geheime Schlüssel wird pro Benutzer in der Tabelle tfa_user_config gespeichert und als QR-Code beim ersten Login präsentiert.

Der Provider Duo Security bindet die Duo-Cloud-Infrastruktur über eine dedizierte API an und ist besonders für Unternehmen relevant, die bereits eine bestehende Duo-Infrastruktur für andere Systeme betreiben. Er erfordert die Konfiguration von Integration Key, Secret Key und API-Hostname in der system.xml-Sektion und funktioniert über Push-Benachrichtigungen an eine mobile App, was aus Benutzersicht komfortabler ist als das manuelle Eintippen eines TOTP-Codes, aber eine Abhängigkeit zu einem externen Cloud-Dienst mitbringt. Der Provider U2F, technisch mittlerweile über WebAuthn realisiert, nutzt physische Hardware-Token wie YubiKeys oder plattformgebundene Authenticators wie Touch ID und Windows Hello. Er bietet das höchste Sicherheitsniveau, weil der private Schlüssel niemals das Gerät verlässt und Phishing durch die Origin-Bindung des WebAuthn-Protokolls praktisch ausgeschlossen ist. Authy schließlich fungiert primär als TOTP-kompatible App und wird über denselben google-Provider unterstützt, sofern der geteilte Schlüssel korrekt importiert wird.

Für die Auswahl des richtigen Providers ist entscheidend, wie viele Admin-Benutzer ein Shop hat und wie hoch das Schutzniveau sein muss. Kleinere Teams fahren mit TOTP über Google Authenticator meist am pragmatischsten, während größere Organisationen mit strengeren Compliance-Anforderungen von U2F/WebAuthn oder Duo Security profitieren. Zwei-Faktor-Authentifizierung sollte dabei nie isoliert für einzelne Benutzer, sondern konsistent für alle Adminrollen mit Schreibzugriff eingeführt werden, damit keine ungeschützte Hintertür bestehen bleibt.

4. 2FA erzwingen: global vs. pro Rolle

Die einfachste Form der Erzwingung ist die globale Konfiguration über force_providers, die für jeden Admin-Benutzer ohne Ausnahme gilt. Das ist die empfohlene Einstellung für produktive Shops, weil ein einzelner nicht abgesicherter Account das gesamte Sicherheitskonzept untergraben würde. In der Praxis ist es dennoch häufig gewünscht, die Erzwingung zeitlich gestaffelt einzuführen: zunächst als optionales Angebot für Administratoren, dann nach einer Übergangsfrist verpflichtend für alle.

Für eine rollenbasierte Differenzierung, etwa strengere Anforderungen für Super-Administratoren als für Support-Mitarbeiter mit eingeschränkten ACL-Rechten, reicht die Standardkonfiguration von Magento_TwoFactorAuth allein nicht aus. Hier bietet sich ein Plugin auf Magento\TwoFactorAuth\Model\Provider\Engine\Google oder direkt auf der AuthenticationInterface an, das die zugewiesene Rolle des Benutzers prüft und je nach Rollen-ID unterschiedliche Provider-Anforderungen durchsetzt. Wichtig ist, dass ein solches Plugin niemals die 2FA-Prüfung vollständig umgeht, sondern lediglich zwischen verschiedenen erzwungenen Providern unterscheidet, damit kein Bypass-Pfad für Zwei-Faktor-Authentifizierung entsteht.

Ein häufig übersehener Aspekt: Die Erzwingung von Zwei-Faktor-Authentifizierung gilt pro Admin-Website-Konfigurationswert, nicht pro einzelnem Benutzerkonto. Wird ein neuer Provider zur force_providers-Liste hinzugefügt, müssen sich alle bestehenden Admin-Benutzer beim nächsten Login neu registrieren, sofern sie den entsprechenden Provider noch nicht konfiguriert haben. Das kann bei überraschenden Konfigurationsänderungen kurzfristig zu Support-Anfragen führen, weil Benutzer plötzlich einen QR-Code scannen müssen, den sie nicht erwartet haben.

5. Die security:tfa CLI-Befehle im Detail

Magento_TwoFactorAuth bringt eine eigene Reihe von CLI-Befehlen unter dem Namensraum security:tfa mit, die insbesondere für administrative Notfälle und Automatisierung unverzichtbar sind. Der Befehl bin/magento security:tfa:google:remove-secret entfernt den TOTP-Geheimschlüssel eines bestimmten Admin-Benutzers und ist der Standardweg, um einen ausgesperrten Administrator wieder zugriffsfähig zu machen, ohne die gesamte 2FA-Konfiguration zu deaktivieren. Der Aufruf erwartet den Benutzernamen als Parameter und setzt den Registrierungsstatus für diesen Provider zurück, sodass beim nächsten Login erneut ein QR-Code angezeigt wird.

Der Befehl bin/magento security:tfa:u2f:remove-registrations löscht alle registrierten U2F/WebAuthn-Token eines Benutzers, was insbesondere dann notwendig wird, wenn ein Hardware-Token verloren gegangen ist oder ein Mitarbeiter das Unternehmen verlassen hat. Es empfiehlt sich, diese Befehle in ein dokumentiertes Runbook für den Support aufzunehmen, weil sie im Ernstfall unter Zeitdruck korrekt ausgeführt werden müssen. Ohne CLI-Zugriff auf den Produktionsserver bleibt einem ausgesperrten Administrator sonst nur der Weg über die Datenbank, was fehleranfälliger und schwerer nachvollziehbar ist.

# List all available TFA providers with their current status
bin/magento security:tfa:google:remove-secret admin_username

# Remove all U2F / WebAuthn registrations for a locked-out user
bin/magento security:tfa:u2f:remove-registrations admin_username

# Force a full reset of all providers for a single admin user
# (run both commands together for a clean re-enrollment)
bin/magento security:tfa:google:remove-secret support_user
bin/magento security:tfa:u2f:remove-registrations support_user

# Inspect module status before disabling in a staging environment
bin/magento module:status Magento_TwoFactorAuth

# Disable the module temporarily on staging only, never on production
bin/magento module:disable Magento_TwoFactorAuth

Ein weiterer wichtiger Befehl im Umfeld der Provider-Verwaltung ist bin/magento module:disable Magento_TwoFactorAuth, der jedoch mit äußerster Vorsicht zu verwenden ist. Er deaktiviert Zwei-Faktor-Authentifizierung vollständig für alle Admin-Benutzer und sollte ausschließlich auf isolierten Entwicklungs- oder Testumgebungen eingesetzt werden, niemals auf einem produktiven oder produktionsnahen Staging-System mit echten Kundendaten. In Abschnitt neun wird dieser Punkt als eine der häufigsten operativen Fallen näher beleuchtet.

6. Eigenen TFA-Provider mit ProviderInterface implementieren

Für Unternehmen mit einer bestehenden Identity-Provider-Infrastruktur, etwa einem internen SSO-System oder einem spezialisierten Hardware-Sicherheitsmodul, lohnt sich die Implementierung eines eigenen Providers für Zwei-Faktor-Authentifizierung. Die Grundlage bildet das Interface Magento\TwoFactorAuth\Api\ProviderInterface, das Methoden wie getCode(), isActive(), isApplicableToUser() und getConfiguration() vorschreibt. Ein eigener Provider muss zusätzlich häufig das Interface Magento\TwoFactorAuth\Api\ProviderInfoInterface implementieren, das Metadaten wie Name und Beschreibung des Providers für die UI-Auswahl bereitstellt.

Die folgende Beispielimplementierung zeigt einen minimalen, aber vollständig funktionsfähigen Provider, der Codes über einen internen Enterprise-SSO-Dienst validiert. Er nutzt Constructor Property Promotion nach PHP 8.4-Konventionen und hält externe Abhängigkeiten über Service Contracts sauber getrennt.

<?php

declare(strict_types=1);

namespace Mironsoft\Security\Model\Provider;

use Magento\TwoFactorAuth\Api\ProviderInfoInterface;
use Magento\TwoFactorAuth\Api\ProviderInterface;
use Magento\TwoFactorAuth\Api\Data\ProviderInfoInterfaceFactory;
use Magento\User\Api\Data\UserInterface;
use Mironsoft\Security\Api\EnterpriseSsoClientInterface;

/**
 * Custom TFA provider that validates codes against an internal
 * enterprise SSO service instead of a local TOTP secret.
 */
class EnterpriseSsoProvider implements ProviderInterface, ProviderInfoInterface
{
    public const CODE = 'enterprise_sso';

    /**
     * @param EnterpriseSsoClientInterface $ssoClient Client that talks to the internal SSO service.
     * @param ProviderInfoInterfaceFactory $providerInfoFactory Factory for provider metadata objects.
     * @param bool $enabled Whether this provider is active, taken from system.xml configuration.
     */
    public function __construct(
        private readonly EnterpriseSsoClientInterface $ssoClient,
        private readonly ProviderInfoInterfaceFactory $providerInfoFactory,
        private readonly bool $enabled = true,
    ) {
    }

    /**
     * Returns the unique provider code used in the provider pool.
     *
     * @return string
     */
    public function getCode(): string
    {
        return self::CODE;
    }

    /**
     * Determines whether this provider is currently active.
     *
     * @return bool
     */
    public function isActive(): bool
    {
        return $this->enabled;
    }

    /**
     * Determines whether this provider applies to the given admin user,
     * e.g. based on a custom user attribute set by the SSO sync job.
     *
     * @param UserInterface $user Admin user being evaluated.
     * @return bool
     */
    public function isApplicableToUser(UserInterface $user): bool
    {
        return (bool) $user->getExtensionAttributes()?->getSsoManaged();
    }

    /**
     * Validates the one-time code entered by the user against the
     * enterprise SSO backend.
     *
     * @param UserInterface $user Admin user attempting to log in.
     * @param string $code Code entered in the admin login form.
     * @return bool
     * @throws \Magento\Framework\Exception\AuthenticationException
     */
    public function verify(UserInterface $user, string $code): bool
    {
        return $this->ssoClient->validateCode((int) $user->getId(), $code);
    }

    /**
     * Returns provider metadata for the TFA provider selection UI.
     *
     * @return ProviderInfoInterface
     */
    public function getConfiguration(): ProviderInfoInterface
    {
        return $this->providerInfoFactory->create([
            'data' => [
                'code' => self::CODE,
                'name' => 'Enterprise SSO',
                'configureAction' => 'mironsoft_security/sso/configure',
            ],
        ]);
    }
}

Der entscheidende Unterschied zu den mitgelieferten Providern liegt in isApplicableToUser(): Ein eigener Provider für Zwei-Faktor-Authentifizierung kann gezielt nur für bestimmte Benutzergruppen aktiv werden, etwa Mitarbeiter, die über den zentralen SSO-Dienst verwaltet werden, während lokale Admin-Accounts weiterhin TOTP nutzen. Diese Flexibilität macht ProviderInterface zu einem mächtigen Erweiterungspunkt, der über die vier Standard-Provider von Magento_TwoFactorAuth deutlich hinausgeht.

7. Provider-Pool in di.xml registrieren

Damit Magento den neuen Provider erkennt, muss er in den zentralen Provider-Pool eingehängt werden. Magento_TwoFactorAuth verwaltet alle registrierten Provider über einen virtualType namens Magento\TwoFactorAuth\Model\Provider\Pool, der als ArrayList konfiguriert ist und dem im di.xml ein zusätzlicher Eintrag hinzugefügt wird. Die Sortierreihenfolge (sortOrder) bestimmt, in welcher Reihenfolge Provider dem Benutzer in der Auswahl präsentiert werden, was insbesondere bei mehreren gleichzeitig erzwungenen Providern relevant ist.

<!-- app/code/Mironsoft/Security/etc/di.xml -->
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">

    <!-- Register the custom provider as a plain service class -->
    <preference for="Mironsoft\Security\Api\EnterpriseSsoClientInterface"
                type="Mironsoft\Security\Model\EnterpriseSsoClient"/>

    <type name="Mironsoft\Security\Model\Provider\EnterpriseSsoProvider">
        <arguments>
            <argument name="enabled" xsi:type="boolean">true</argument>
        </arguments>
    </type>

    <!-- Hook into the existing TFA provider pool -->
    <virtualType name="Magento\TwoFactorAuth\Model\Provider\Pool">
        <arguments>
            <argument name="providers" xsi:type="array">
                <item name="enterprise_sso" xsi:type="array">
                    <item name="instance" xsi:type="string">
                        Mironsoft\Security\Model\Provider\EnterpriseSsoProvider
                    </item>
                    <item name="sortOrder" xsi:type="number">50</item>
                </item>
            </argument>
        </arguments>
    </virtualType>
</config>

Nach dem Deployment dieser di.xml-Änderung erscheint der neue Provider automatisch in der Liste der auswählbaren Provider unter der system.xml-Konfiguration force_providers, ohne dass an der Kernlogik von Magento_TwoFactorAuth etwas verändert werden musste. Das ist der zentrale Vorteil des Pool-Patterns: Erweiterungen für Zwei-Faktor-Authentifizierung erfolgen additiv über Dependency Injection, nicht über Preferences auf Kernklassen, was Upgrades auf spätere Magento-Versionen erheblich vereinfacht. Nach jeder Änderung an di.xml ist ein bin/magento cache:flush sowie in produktiven Setups ein setup:di:compile erforderlich, damit der Objekt-Manager die neue Konfiguration übernimmt.

8. 2FA im Headless-Kontext: REST, GraphQL und Recovery Codes

Ein häufiges Missverständnis betrifft die Reichweite von Zwei-Faktor-Authentifizierung in headless Architekturen, in denen ein PWA-Studio-Frontend oder eine eigene Storefront ausschließlich über REST- oder GraphQL-APIs mit Magento kommuniziert. Zwei-Faktor-Authentifizierung ist ausschließlich ein UI-Layer-Feature des Adminbereichs und greift ausschließlich beim interaktiven Login über die Backend-Oberfläche. Token-basierte Authentifizierung für Kunden über REST (customerToken) oder GraphQL (generateCustomerToken) ist von Zwei-Faktor-Authentifizierung vollständig unberührt, weil es sich um zwei völlig unabhängige Sicherheitsschichten handelt: die eine schützt Kundenkonten im Frontend, die andere schützt administrative Zugriffe im Backend.

Für Integrationen, die Admin-Tokens programmatisch erzeugen, etwa über integrationToken für Drittsystem-Integrationen, greift Zwei-Faktor-Authentifizierung ebenfalls nicht, weil dieser Authentifizierungspfad technisch getrennt von der interaktiven Admin-Session verläuft und stattdessen über OAuth-Zugangsdaten abgesichert wird. Das bedeutet in der Praxis: Ein Angreifer, der versucht, sich über die Admin-UI einzuloggen, wird durch Zwei-Faktor-Authentifizierung gestoppt, während ein API-Client mit gültigen Integrationszugangsdaten unabhängig davon funktioniert. Wer also API-Zugänge absichern will, muss dies über separate Mechanismen wie IP-Whitelisting für die REST-Endpunkte, kurze Token-Lebensdauern und ein sauberes Scope-Management der Integrationsrechte tun, nicht über Zwei-Faktor-Authentifizierung.

Für den Fall, dass ein Admin-Benutzer seinen zweiten Faktor verliert, etwa ein defektes Smartphone mit der Authenticator-App oder ein verlegter Hardware-Token, bietet Magento_TwoFactorAuth kein integriertes Backup-Code-System wie viele SaaS-Anwendungen. Stattdessen übernimmt ein Administrator mit Zugriff auf die security:tfa-CLI-Befehle die Rolle der Recovery-Instanz und setzt den betroffenen Provider für den Benutzer zurück. Größere Organisationen ergänzen dies häufig um einen eigenen Recovery-Code-Mechanismus als zusätzlichen Custom-Provider, der beim initialen Setup einmalige Einmalcodes generiert und diese verschlüsselt in der Datenbank hinterlegt, damit ein Nutzer sich im Notfall selbst ohne administrativen Eingriff wieder anmelden kann.

9. Typische Stolperfallen im Betrieb

Die häufigste operative Falle bei Zwei-Faktor-Authentifizierung entsteht während der Entwicklung: Ein Entwickler deaktiviert Magento_TwoFactorAuth auf einer Staging-Umgebung, um schneller testen zu können, ohne bei jedem Login einen TOTP-Code eingeben zu müssen, und vergisst anschließend, das Modul vor dem Deployment auf die Produktionsumgebung wieder zu aktivieren. Da Magento-Modulstatus über app/etc/config.php versioniert wird, kann ein solcher Zustand unbemerkt in die Produktion gelangen, wenn die Konfigurationsdatei ungeprüft übernommen wird. Ein verlässlicher Schutz dagegen ist ein automatisierter Check in der Deployment-Pipeline, der vor jedem Produktions-Deployment prüft, ob Magento_TwoFactorAuth im Modulstatus als aktiv eingetragen ist, und das Deployment bei Abweichung blockiert.

Eine zweite häufige Falle betrifft das versehentliche Aussperren des eigenen Admin-Zugangs beim erstmaligen Testen von Zwei-Faktor-Authentifizierung auf einer neuen Umgebung. Wird force_providers gesetzt, bevor der eigene TOTP-Code korrekt eingerichtet und getestet wurde, kann der Zugriff auf den Adminbereich vollständig blockiert sein. Für diesen Fall ist der direkte Datenbankzugriff oder die CLI-Befehle aus Abschnitt fünf der einzige Ausweg, weshalb es sich empfiehlt, vor jeder Änderung an der 2FA-Konfiguration einen zweiten, unabhängig authentifizierten Admin-Zugang bereitzuhalten.

Eine dritte, technisch subtilere Falle betrifft den Betrieb hinter einem Reverse-Proxy oder Load-Balancer bei der Nutzung von U2F/WebAuthn. Das WebAuthn-Protokoll bindet jede Signatur kryptografisch an die Origin, also das Protokoll, den Hostnamen und optional den Port, unter dem der Adminbereich aufgerufen wird. Wird die relying_party_id in der system.xml-Konfiguration nicht exakt auf die öffentlich sichtbare Domain gesetzt, oder terminiert ein Reverse-Proxy TLS und leitet Requests über HTTP an den Magento-Container weiter, ohne den korrekten X-Forwarded-Proto-Header weiterzureichen, schlägt der Origin-Check von WebAuthn fehl und Benutzer können sich nicht mehr mit ihrem Hardware-Token anmelden. Die Lösung ist, den Reverse-Proxy so zu konfigurieren, dass er X-Forwarded-Proto und X-Forwarded-Host korrekt setzt, und in Magento über den Parameter trusted_proxies in app/etc/env.php die vertrauenswürdigen Proxy-IP-Adressen einzutragen, damit Magento die tatsächliche Origin korrekt ermittelt statt der internen Proxy-Adresse.

10. Zusammenfassung

Zwei-Faktor-Authentifizierung im Magento-2-Adminbereich basiert auf dem Kernmodul Magento_TwoFactorAuth, das mehrere Provider unterstützt, von einfachem TOTP über U2F/WebAuthn bis hin zu selbst implementierten Providern für bestehende SSO-Infrastruktur. Über die Konfiguration force_providers lässt sich 2FA für alle Administratoren verpflichtend machen, während CLI-Befehle wie security:tfa:reset und security:tfa:show-providers Notfallzugriff und Provider-Übersicht ermöglichen, falls ein Administrator ausgesperrt wird.

Die drei größten operativen Risiken sind ein versehentlich deaktiviertes Modul auf dem Weg von Staging zu Produktion, ein zu frühes Erzwingen von force_providers vor dem ersten erfolgreichen Test, und ein falsch konfigurierter Reverse-Proxy, der die Origin-Prüfung von WebAuthn zum Scheitern bringt. Wer diese drei Fallen kennt und einen zweiten, unabhängig authentifizierten Notfall-Zugang bereithält, kann 2FA ohne Aussperrungsrisiko produktiv ausrollen.

11. FAQ: Zwei-Faktor-Authentifizierung im Magento-Admin