Talk Handout · SCD 2026
Identity & Access Management in Shopware
Eine Identität, jede Tür. Ein praxisnaher Blick darauf, wie moderne Logins, Identity Provider und Protokolle den Zugang einfacher, sicherer und alltagstauglich machen.
Weniger Passwörter, weniger Probleme
Menschen sind schlecht mit Passwörtern. Wir verwenden sie mehrfach, vergessen sie und jedes weitere, das wir uns merken müssen, ist ein weiteres Geheimnis, das gephisht, geleakt oder unachtsam auf einem Zettel notiert werden kann. Der wirksamste Weg, Logins sicherer zu machen, ist daher keine strengere Passwortrichtlinie. Es ist die Anzahl der Passwörter zu reduzieren.
Genau das leistet Identity & Access Management: eine vertrauenswürdige Identität, wiederverwendet in jedem System, sodass die Frage nicht mehr lautet „Was war nochmal mein Passwort?" sondern „Warum bin ich nicht schon eingeloggt?" Im Folgenden finden sich die Bausteine und die Punkte, an denen wir sie bereits für Shopware 6 umsetzen.
Tiefer einsteigen
Wer tiefer in die Materie abtauchen möchte, startet mit unserem Open-Source-Plugin und liest anschließend die Standards, auf denen es aufbaut:
- Admin OpenAuth Plugin auf GitHub – unser Quellcode (Englisch)
- Das Plugin im Shopware Store
- Wie OpenID Connect funktioniert – openid.net (Englisch)
- Das OAuth 2.0 Framework – RFC 6749 (Englisch)
Gleicher Aufwand, größere Reichweite
Das Anlegen eines klassischen Administrationskontos und die Einrichtung eines passwortbasierten Logins erfordert jeweils etwa dieselben sechs Informationen. Ein Konto davon dient nur einer einzigen Person in einer App, die andere Einrichten kann allen Nutzen dienen.
Klassisches Konto
Ein Shopware-Administrationskonto
Etwa sechs Felder zum Ausfüllen:
- Vorname, Nachname und E-Mail-Adresse
- Benutzername, Passwort und Berechtigungen
Und dann wieder …
- für jedes Konto und jede Umgebung
- zum Einloggen sind trotzdem noch zwei Angaben nötig
Funktioniert für jeden
Ein OpenID Connect-basierter Login
Auch etwa sechs Eingaben:
- Name, Berechtigungen und Scopes
- OpenID-Konfiguration, Client ID und Client Secret
Aber diesmal …
- einmalig pro Zielgruppe und Umgebung einrichten
- ein einzelner Klick oder eine automatische Weiterleitung meldet den Nutzer an
Wir bringen das in Shopware 6
Das ist nicht nur Theorie: Wir stellen es in beide Richtungen bereit. Mit unserem kostenlosen SSO Admin Login Plugin meldet sich das Team mit der Identität, die es schon hat, in der Shopware 6-Administration an – über Microsoft Entra (Azure AD) und andere OAuth2-Provider. Kein eigenes Admin-Passwort, das angelegt, geändert oder vergessen werden kann.
Und auch in die andere Richtung: Unsere Erweiterung „Shopware als OAuth-Provider" ermöglicht es Kunden, ihr Shop-Konto für die Anmeldung bei Drittanbieterdiensten zu nutzen. Ein „Mit Ihrer Marke anmelden"-Button, den Sie von Anfang bis Ende selbst kontrollieren.
Richtig umgesetzt ist der Wechsel auch für bestehende Nutzer nahtlos: Kunden behalten ihre Konten und steigen ohne Unterbrechung auf den neuen Login um.
OAuth, in beide Richtungen
- Microsoft Login – OAuth2-Anmeldung für die Shopware 6-Administration (Microsoft Entra / Azure AD, Atlassian Access)
- Shopware als OAuth-Provider – Kunden ermöglichen, sich mit ihrem Shop-Konto bei anderen Diensten anzumelden
Die Sprache rund um digitale Identität
Eine schnelle Referenz für die Begriffe, die immer wieder auftauchen, wenn über Logins, Identity Provider und Access Management gesprochen wird.
- SSO – Single Sign-On
- Einmal anmelden, überall eingeloggt bleiben. Eine authentifizierte Sitzung wird von jeder verbundenen Anwendung akzeptiert, sodass Nutzer keine Zugangsdaten erneut eingeben müssen, wenn sie vom Shop zum Helpdesk zum Admin-Bereich wechseln – eine Identität statt eines separaten Kontos pro Tool.
- IdP – Identity Provider
- Das zentrale System, das weiß, wer alle sind, und die Tokens ausstellt, denen die anderen Anwendungen vertrauen. Entweder wird ein verwalteter Dienst in der Cloud genutzt (Microsoft Entra, Google Workspace, Okta, cidaas …) oder ein eigener betrieben. Keycloak ist die klassische selbst gehostete Wahl, wenn die Daten auf eigenen Servern bleiben sollen.
- Workforce Identity Management
- Die Logins der eigenen Mitarbeitenden und Administratoren – Eintritt, Wechsel und Austritt. Der Mehrwert liegt in der Governance: Wer darf auf was zugreifen, und der Zugang wird sofort entzogen, wenn jemand das Unternehmen verlässt.
- Customer Identity Management
- Die Logins der Kunden, meist in wesentlich größerem Umfang. Hier stehen reibungslose Registrierung, Self-Service und ein Konto, das über Shop, Support und Dienste hinweg funktioniert, im Vordergrund.
- OAuth 2.0 & OpenID Connect
- OAuth 2.0 ist ein Framework für delegierte Autorisierung: Eine Anwendung erhält begrenzten, auf Scopes beschränkten Zugriff im Namen eines Nutzers, ohne jemals sein Passwort zu sehen. OpenID Connect fügt eine Authentifizierungsschicht hinzu, sodass die App auch erfährt, wer der Nutzer ist. Zusammen bilden sie die Grundlage der meisten modernen „Anmelden mit …"-Buttons – und des Flows, den unser Shopware-Plugin verwendet.
- SAML
- Ein älterer, aber bewährter Standard, der Benutzerinformationen in XML austauscht, in der Regel über den Browser des Nutzers weitergeleitet. Ist in vielen Enterprise- und Workforce-SSO-Setups noch die Standardlösung.
- SCIM
- Hält Nutzer und Gruppen automatisch synchron: Wenn jemand im IdP hinzugefügt, geändert oder deaktiviert wird, provisioniert oder deprovisioniert SCIM die notwendigen Informationen in den verbundenen Anwendungen – ohne jedes Konto manuell pflegen zu müssen.
- cXML / OCI PunchOut
- Protokolle für die Beschaffung verknüpfter Kataloge, keine reinen Login-Standards, und sie funktionieren in beide Richtungen: Der Shop kann der Katalog sein, in den Einkäufer aus ihrem eigenen Beschaffungssystem einsteigen, oder der Shop kann in den Katalog eines Lieferanten wechseln. In beiden Fällen wird die Identität mitgeführt, sodass jeder Warenkorb und jede Bestellung der richtigen Person zugeordnet bleibt.
Was sich damit umsetzen lässt
Identität ist kein abstraktes Sicherheitsthema – sie taucht beim Onboarding auf, in Lagerhallen, an der Eingangstür und in Systemen, die eigenständig miteinander kommunizieren.
Eigenen IdP betreiben
Eigene Daten, eigene Kontrolle, eigene Souveränität – alles bleibt nah an den eigenen Servern. Eigene Tools hosten und Nutzern ermöglichen, sich mit demselben Login anzumelden, den sie schon im Shop verwenden.
FIDO2 mit einem Hardware-Token
Den Login auf einem Hardware-Token wie einem YubiKey speichern – der eigene Fingerabdruck kann der Login sein. Derselbe Gedanke lässt sich in die physische Welt übertragen: Kundenkarten, die Zugang zu online gebuchten Veranstaltungsorten gewähren.
Logins in der realen Welt nutzen
Türen, MDM und WLAN laufen auf derselben Identität: Derselbe Login, der eine Tür öffnet, entsperrt auch das Netzwerk dahinter. Ein neues MacBook erkennt beim Onboarding, wer man ist, und installiert vorab, was man braucht – UniFi und cidaas integrieren sich nahtlos in den Alltag.
Service-Accounts mit OAuth2
Identitäten müssen keine Menschen sein. Service-Accounts, die im Namen einer Rolle handeln, können dieselben Protokolle – einschließlich OAuth2 – zur Authentifizierung verwenden.
Identity Provider verketten
Keycloak nutzen, aber schon in Microsoft zuhause? Google Workspace, aber Microsoft wird auch benötigt? Viele Provider erlauben es, sich über einen anderen anzumelden, sodass bestehende Systeme einfach verbunden werden können.
Zeitbasierte Richtlinien
Zeitbasierte Regeln für automatisches Off-Boarding oder Self-Onboarding nutzen – Zugänge, die sich zu dem Zeitpunkt gewähren und entziehen, zu dem es sein soll.
Fragen Sie sich
Wenn ein Login Sie das nächste Mal aufhält, sind zwei Fragen besonders wichtig:
- Warum bin ich noch nicht eingeloggt?
- Welche Daten habe ich eigentlich?
Wenn die Antwort lautet „weil Identität nicht von Anfang an mitgedacht wurde", dann ist genau das der Punkt, an dem wir helfen können.
In Kontakt bleiben
Fragen zu Identity & Access Management für Ihren Shop oder Ihre Organisation?
Sprechen Sie uns an
