Wir haben Shopware 6.6.10.2 installiert um am Mailer Oauth2 zu nutzen. Leider bekommen wir einen Fehler beim Mailversand und denken dass es am der OAuth URL liegt.
Kann uns jemand helfen, was an der Redirect_URI rein muss?
Tenant und Client_ID haben wir aus Entra, eine Web registrierung für die Redirect URI auch, allerdings ist auch hier unklar, von welcher URL der ShopMailer dies abruft.
Wir haben das gleiche Problem.
Die Shopware 6 Dokumentation zu Mailer Shopware 6 - Einstellungen - Mailer lieferert dazu ein Bild für Office 365.
Leider ist in diesem nicht ersichtbar welche OAuth URL eingetragen werden soll.
Da scope und Client ID getrennt abgefragt wird ist nicht ersichtlich welche Form der Authentifizierung von Shopware verwendet wird. Ein paar Tests haben bei mir zu keinem Erfolg geführt. Der Verweis auf die Dokumentation von Microsoft hilft hier nicht weiter, weil Microsoft die von Shopware verwendete Methode nicht kennt. Hat jemand aus dem Forum bereits einen erfolgreichen Versand von Mails geschafft und kann beschreiben welche Einstellungen nötig sind? Vielen Dank.
wir schließen uns an, wir haben dasselbe Problem. Das Service Principal ist soweit angelegt. Die übrigen Felder in der Eingabemaske auch klar, bekommen aber die OAuth URL nicht sinnvoll gefüllt.
Wir haben genau das gleiche Problem und kommen nicht weiter. Unser System steht in der Cloud. Gibt es hier jemanden der schon positive Erfahrungen gesammelt hat?
Oauth URL: https://login.microsoftonline.com/{Tenant}/oauth2/v2.0/token -> ersetzen Sie {Tenant} mit „Directory (Tenant) ID“ aus App Registrations -> Overview im Microsoft Entra Admin Center
Es ist wichtig, dass alle Schritte ausgeführt werden, damit die Mails funktionieren.
Ihr könnt unter Einstellungen > Ereignisprotokolle in der Verwaltung nach Fehlern suchen, wir haben dort eine zusätzliche Protokollierung hinzugefügt.
Aber die korrekte URL von dem jeweiligen Provider herauszufinden ist tatsächlich eine große Herausforderung, wie ich mir habe sagen lassen
Das Problem ist, egal was ich bei OAuth-URL (einfach mal nur google.com eingetragen) oder Client-Id (wahllose wirre Zeichenkette) Eintrage, es kommt immer der gleiche Fehler:
Expected response code „250“ but got code „530“, with message "530 5.7.57 Client not authenticated to send mail.
@Benjamin_Hummel
Habt ihr das intern schon zum Laufen bekommen und wenn ja, wie?
Ich kenne es aus einem WordPress-Projekt. Da musste man im Plugin vergleichbare Daten wie oben angeben, dann gab es aber einen Authorize-Button, der auf MS weitergeleitet hat. Nach der Eingabe des eigentlichen MS-Accounts, wurde über eine Redirecct-URL zum Plugin (in Entra hinterlegt) weitergeleitet und fertig.
Der ganze OAuth-Prozess zum Abrufen des Tokens fehlt in Shopware, oder? Und ich muss das manuell über irgendwelche Client-Bibliotheken (siehe MS Doku) erledigen? Wenn ja, ist das für Kunden kaum zu gebrauchen. Ist ja schon eine Herausforderung in Entra alles soweit einzurichten.
Hier hätte ich auch gerne eine intuitive Lösung? Wir sind noch nicht umgestiegen, weil wir auch noch nicht müssen und haben noch Shopware 6.6.9.0. Wenn ich allerdings hier lese wie kompliziert das mittlerweile geworden ist sowas simples wie den Mailer mit OAuth einzurichten…
Ich fürchte fast, dass es an der Stelle nicht klappen wird. Unsere Anwendung unterstützt bewusst ausschließlich das SMTP-Standardprotokoll, um Händler:innen die freie Wahl des SMTP-Anbieters zu ermöglichen.
Ich bin nicht der m365 Profi aber aufgrund eines parallelen Falles kam wohl heraus, wenn ich das richtig verstanden habe, dass die Verbindung zu m365 wohl von Microsoft nur über die sogenannte Graph-API möglich ist.
Das wiederum ist aber derzeit noch nicht im Admin möglich
Ich versuche das Thema gerne zu pushen, aber momentan geht es nur über das smtp Protokoll. Das wird aber glaube ich von Microsoft einschränkt in Kürze? Irgendetwas in der Art.
Wir müssten uns also mit der Graph-API beschäftigen, oder jemand genau dafür eine Erweiterung schaffen, die entsprechend auf die bisherigen Möglichkeiten aufsetzt.
Laut ChatGPT ist Oktober 2025 dann Feierabend mit SMTP. Also bitte schnell umsetzen lassen, dass es vollständig, intuitiv und alles über den Admin funktioniert. Hier steht auch was von Microsoft Graph:
Microsoft ist im Laufe der letzten Jahre schrittweise zu einer reinen OAuth 2.0‑Authentifizierung übergegangen – insbesondere bei Microsoft 365- und Exchange-Online-Diensten.
Wechsel weg von Basic Auth (OAuth 1 / Legacy)
Basic Authentication (Username/Passwort)
Für Exchange Online (EWS, IMAP, POP, Remote PowerShell, Exchange ActiveSync) wurde Basic Authentication am 1. Oktober 2022 deaktiviert – nur Modern Authentication (OAuth 2.0) ist seitdem in der Cloud nutzbar.
Legacy Exchange Online Tokens für Outlook Add-ins
Ein besonderer Fall betrifft sogenannte Exchange Legacy Tokens in Outlook webbasierten Add-Ins:
Zeitpunkt
Ereignis
Februar 2025
Deaktivierung dieser Tokens als Standard – Add‑Ins müssen migriert werden, sonst brechen sie.
Juni 2025
Admins verlieren Möglichkeit, diese Tokens wieder zu aktivieren.
Oktober 2025
Legacy Tokens sind komplett abgeschaltet, auch bei ggf. reaktivierten Add‑Ins.
Fazit – Wann gibt es nur noch OAuth 2?
Ab 1. Oktober 2022: Legacy Basic Authentication ist für Exchange Online nicht mehr verfügbar – sämtliche Kommunikation muss per OAuth 2.0 erfolgen.
Bis 2025: Einige Outlook-Web‑Add‑Ins konnten noch Legacy Tokens verwenden, aber ab Oktober 2025 ist auch das endgültig vorbei.
Andere APIs (wie etwa Outlook REST API v1/v2) wurden teilweise schon früher eingestellt und durch Microsoft Graph mit OAuth2 ersetzt.
Was bedeutet das konkret?
Anwendungen oder Skripte, die über Benutzername/Passwort (Basic Auth) auf Exchange Online zugreifen, funktionieren nicht mehr.
Stattdessen werden OAuth 2.0-Flows und die Nutzung von Microsoft Graph APIs empfohlen.
Entwickler sollten sicherstellen, dass alle Add-Ins oder Programme, die Exchange Online nutzen, vollständig auf moderne Authentifizierung migriert haben.
Kurz gesagt:
Seit Oktober 2022 ist Microsoft auf OAuth 2.0 umgestiegen — und ab Oktober 2025 wird alles ohne Ausnahme ausschließlich OAuth 2.0 nutzen.
Meine Meinung: Das hat Shopware leider stark schleifen lassen. Als es noch möglich war auf issues.shopware.com Funktionsvorschläge aufzunehmen, gabs einen Vorschlag bereits vor Jahren. Der erste Forumseintrag hier war von Ende 2020.
Also können bald alle Betroffenen 49 EUR/Monat löhnen, nur das Mails rausgehen?!: Unterschiedliche (SMTP) Mailer je Verkaufskanal einstellen + OAuth2 Support
Ich bin nicht der m365 Profi aber aufgrund eines parallelen Falles kam wohl heraus, wenn ich das richtig verstanden habe, dass die Verbindung zu m365 wohl von Microsoft nur über die sogenannte Graph-API möglich ist.
Nein, das ist meines Erachtens falsch:
Erfahren Sie, wie Sie die OAuth-Authentifizierung verwenden, um eine Verbindung mit IMAP-, POP- oder SMTP-Protokollen herzustellen und auf E-Mail-Daten für Office 365-Benutzende zuzugreifen.
Und es gibt genügend Beispiele, z.B. aus der WordPress-Welt, die MS365-SMTP per OAuth anbinden.
Ich kann mir aber nicht vorstellen, dass die OAuth-Anbindung in Shopware überhaupt irgendwo funktioniert, da die Authorize-Funktion komplett fehlt. In WordPress z.B. muss ich die gleichen Daten wie in Shopware eintragen, habe dann aber einen Authorize-Button, der mich einmalig auf die MS-Login-Seite verlinkt - analog zur PayPal-Anbindung.
Und in eurer Doku wird explizit auf MS365 eingegangen:
Als Beispiel haben wir die Einrichtung mittels Office 365 vorgenommen. Eine genaue Anleitung von Microsoft findest du dazu hier. Shopware 6 - Einstellungen - Mailer
Also entweder OAuth mit dem gesamten Prozess implementieren oder komplett rausnehmen.
Gibt’s hier jemand der berichten kann, dass mit der integrierten OAuth 2 Lösung von Shopware erfolgreich eine Verbindung zu MS365 Mailserver herstellen konnte und Mails verschicken konnte?
Alles was ich bisher geschafft habe ist via Graph und Powershell, Mails zu versenden.
Eben mit erstellen einer APP in ENTRA etc.
Aber diese Geschichte hier bedarf einer etwas genaueren Erklärung von allen Seiten.
Ich will doch nur Spi… äh Info Mails versenden.
Oder/Und eine deutliche Vereinfachung des vorgehens.
Ich habe mich über den Support von Shopware durchgearbeitet, so das eine Antwort vom Entwicklerteam von Shopware kam:
Zitat:
Microsoft unterstützt derzeit keine Authentifizierung über OAuth in Verbindung mit dem SMTP-Protokoll. Dieses Verhalten ist Microsoft-seitig und betrifft nicht unsere Anwendung – andere Anbieter unterstützen OAuth über SMTP problemlos. Microsoft bestätigt auch selbst, dass sie diese Kombination nicht unterstützen.
Stattdessen empfiehlt Microsoft die Verwendung der Graph API zur Authentifizierung. Unsere Anwendung unterstützt jedoch bewusst ausschließlich das SMTP-Standardprotokoll, um Händler:innen die freie Wahl des SMTP-Anbieters zu ermöglichen. Wer dennoch Microsoft Graph API nutzen möchte, müsste hierfür eine individuelle Lösung (z. B. in Form eines eigenen Plugins) implementieren. Eine solche Implementierung ist allerdings sehr spezifisch und wird unsererseits nicht bereitgestellt.
Als alternative Option schlägt Microsoft die klassische SMTP-Authentifizierung (ohne OAuth) vor. Diese Methode wird von unserer Anwendung direkt und vollständig unterstützt. Die konkrete Konfiguration auf Microsoft-Seite liegt allerdings außerhalb unseres Supports – hier empfehlen wir, ggf. den Microsoft-Support direkt zu kontaktieren.
Zitat Ende
Dazu wurde noch geschrieben, das Shopware das “schnellstmöglich” beheben möchte.
Was das bedeutet, steht aber in den Sternen.
Ein Entwickler eines Plugins, hat sich auch bei mir gemeldet, er möchte das selber in seinem Plugin integrieren. Bis jetzt, aber noch nicht vorhanden. Wenn der schneller ist, werde ich das hier Posten
wir haben einen Shopware 6.x Shop erfolgreich mit der standardmäßig vorhandenen oAuth Integration mit Office 365 verbunden, Shopware hat alles, was dafür notwendig ist. Der Teufel liegt hier aber im Detail.
Es ist erstmal wichtig zu verstehen, dass oAuth verschiedene Authentifzierungs-Flows kennt:
Authorization Code Flows setzen eine aktive Benutzerbeteiligung voraus; das ist der hier schon mehrfach erwähnte Flow mit “Authorize” Button
Device Flows setzen ebenfalls eine aktive Benutzerbeteiligung voraus
Client Credential Flows hingegen sind für Maschine-zu-Maschine Kommunikation gedacht und brauchen daher keine Benutzeraktion - und genau diese Art von Flow nutzt Shopware für SMTP via oAuth
Jetzt kommt das entscheidende Detail: MS365 erlaubt bei der Nutzung eines solchen Client Credential Flows standardmäßig nur den Mail-Versand per Graph API und nicht per SMTP oAuth. Die Nutzung von Client Credential Flows im SMTP Kontext muss explizit konfiguriert und freigeben werden.
In der Doku gibts dazu einen kompletten Abschnitt “Flow zur Gewährung von Clientanmeldeinformationen zum Authentifizieren von SMTP-, IMAP- und POP-Verbindungen verwenden”:
Wenn die dort beschriebenen Schritte korrekt und vollständig ausgeführt sind, funktioniert auch der Versand. Die Info vom Entwicklerteam ist daher meiner Meinung nach falsch - und meine Meinung basiert dabei auf einem funktionierenden Versand
Um der Frage vorzugreifen: in der Shopware Config nutzen wir die Konfigurationsvorgaben aus der Shopware Doku, die sind also korrekt.
Wechsel weg von Basic Auth (OAuth 1 / Legacy)
Basic Authentication (Username/Passwort)
Legacy Exchange Online Tokens für Outlook Add-ins
Fazit – Wann gibt es nur noch OAuth 2?
Was bedeutet das konkret?