Email mit Oauth2

[Ulf346C]

Hallo Forum,

- ich sehe gerade gar kein Land
Ich habe eine Warenwirtschaft am laufen, schon viele Jahre, auch mit einem funktionierenden Mail-Client aus Indy-Komponenten.
Nun tauchen AzureAD/Office365 Mailkonten auf.
Da bekomme ich keinen Zugang per Imap/Smtp. Inzwischen ahbe ich gelernt: Zugriff nur mit Oauth-Identifizierung. Und da beginnt mein Problem: habe gar keine Ahnung - ich bin Datenbanker, mit Webservices habe ich so etwas von gar nichts am Hut

Also meine Frage: lassen sich meine Indy-Komponenten mit Oauth2 verbinden; und wie läuft die Authentifizierung dann ab?

Danke
Ulf

[mjustin]

In meinem (Open Source) Daraja HTTP Framework sind Beispiele zu OAuth2 (und auch zu OpenID Connect) enthalten.
Leider habe ich an diesem Framework seit längerer Zeit nicht mehr arbeiten können. Es basiert auf Indy (genauer: dem Indy HTTP Server).

Der Haken ist: bei OAuth2 wird entweder ein lokaler Webserver eingesetzt (siehe oben) der unter localhost erreichbar ist, oder man muss auf einem anderen Weg an das OAuth2-Authorisierungs-Token gelangen, das der Server mit seiner HTTP-Antwort sendet. Ein einfacher - aber nicht sehr komfortabler - Weg besteht darin, das Token per Copy&Paste aus einer Webseite in den Delphi E-Mail-Client zu übertragen.

Das Access-Token (ja, das ist ein anderes Token das man über das Auth-Token erhält) kann dann im System des Clients gespeichert werden. Dieses verfällt nach einer gewissen Zeit. Je nach Anbieter gibt es daher auch "Refresh"-Token, mit diesen kann wieder ein neues Access-Token generiert werden. Dadurch ist auf dem Client nur einmalig eine Benutzerinteraktion notwendig. Oder wieder dann, wenn der Anbieter das Access-Token für ungültig erklärt.

Daraja HTTP Framework
https://github.com/michaelJustin/daraja-framework

(es gibt auch andere Lösungen für OAuth2-Integrationen für Delphi, das o.g. Framework enthält nur kleine Beispiele, ist also nicht speziell auf einfache OAuth2-Anbindung 'spezialisiert')

[bepe]

Die Anmeldung an einen Exchange mit Modern Auth ist an sich trivial. Derzeit gibts du ein Username und Kennwort an. Bei Modern Auth ersetzt du das Kennwort durch ein Token. (Also weiterhin mit POP3/SMTP/IMAP)

Etwas komplexer ist der Weg zum Token:
- Du musst dein Programm bei MS registrieren. Dort hinterlegst du auch Information zum Hersteller, wie z.B. eine Webseite. Bei der Registrierung bekommt dein Programm eine Client-ID.
- Wenn ein Anwender ein entsprechendes Mail-Konto einrichten möchte, dann musst du eine Login Seite von MS öffnen. Am einfachsten z.B. in einer Webbrowser Komponente. Der Login Seite wird u.a. die Client-ID deines Programms übergeben.
- Auf der Seite kann sich der Anwender mit seinen Office 365 Daten anmelden. Dann wird er gefragt, ob er deinem Programm Zugriff gestatten möchte.
- Gewährt der Anwender Zugriff, wird auf eine Webseite weitergeleitet, welche du hinterlegen kannst. An diese wird das Token übergeben (ich vermute deshalb meinte mjustin, dass ein lokaler Webserver nötig sei). Zumindest bei MS und Google kann man angeben, dass das Token an ein (nicht Web) Programm übergeben werden soll. Dann braucht man keinen Webserver. Das Token kann man aus dem Titel der Webseite oder aus einem Parameter der Redirect URL lesen. redirect_uri wären dann: "urn:ietf:wgauth:2.0ob" bzw. "https://login.microsoftonline.com/common/oauth2/nativeclient"


Das würde ich dir empfehlen:
- Sieh dir das REST bzw. OAUTH Beispielprojekt von Delphi an (ich meine da gibt es eines, in dem u.a. Delphi Praxis angesprochen wird). Und lerne OAUTH2 und dessen Ablauf zu verstehen.
- Wenn du OAUTH verstanden hast, siehe dir die Graph API von MS an. Über diese erhältst du das Token.

Ich würde nicht direkt mit der Graph API anfangen. Die ist doch recht komplex und mit den vielen, teilweise sehr ähnlichen Rechten, teils verwirrend.


Und wegen den Indys:
- Senden und Empfangen kein Problem
- Autorisierung und erstes Token abholen ist bestimmt, teilweise mit Indys machbar. Wäre mir aber viel zu umständlich (es muss eine Webseite angezeigt/gerendert werden). Hier würde ich eine Browserkomponente benutzen
- Mit dem Refreshtoken das Accesstoken aktualsieren funktioniert aber wieder einwandfrei mit Indy



Das müsste das Projekt sein, welches ich meinte:
RESTDemo auf Github

[EarlyBird]

Der Zugang auf Office365 Mailkonten per SMTP funktionierte bei uns problemlos.
Allerdings muss SMTP auch freigeschaltet sein.
Nach der Umstellung der Konten auf Zwei Faktor Authentifizierung mussten wir allerdings für den Zugriff per SMTP App-Kennwärter verwenden.
Damit funktioniert es heute aber auch wieder problemlos.
Hier mal ein paar Infos dazu:
Verwalten von app Kennwörtern

[Ulf346C]

Ich danke euch !

Da muß ich wohl noch ein wenig Gehirnschmalz investieren ...

@earlybird
genau so ging es mir ja auch, mit einzelnen Konten hat es funktioniert
nun, mit Azure AD und neuer Domäne, nicht mehr (die Protokolle sind alle freigegeben, hilft aber nichts)

[ConstantGardener]

@mjustin: Ich hatte deinen Post zu Daraja/Indy und OAuth2 letztens gesehen. Das wäre eine schöne Erweiterung von daraja, wenn das die OAuth2 Sache vereinfachen könnte. Fände ich besser als einen Webbrowser einzubinden und da dann irgendwas auszulesen.

[EarlyBird]

Zitat von Ulf346C:

nun, mit Azure AD und neuer Domäne, nicht mehr (die Protokolle sind alle freigegeben, hilft aber nichts)

Mit dem APP Kennwort funktioniert es nicht?
Das klappt bei uns problemlos

[mjustin]

Zitat von ConstantGardener:

@mjustin: Ich hatte deinen Post zu Daraja/Indy und OAuth2 letztens gesehen. Das wäre eine schöne Erweiterung von daraja, wenn das die OAuth2 Sache vereinfachen könnte. Fände ich besser als einen Webbrowser einzubinden und da dann irgendwas auszulesen.

Danke für den Hinweis! Konkret zu OAuth in Verbindung mit E-Mail enthält das Daraja HTTP Framework keine Beispiele.

Ein Beispiel zur Verwendung von OAuth 2 für den Zugriff gibt es bereits, es wird hier beschrieben:

Google API access with OAuth 2.0 authorization for Daraja HTTP Server Applications (full source code)
https://mikejustin.wordpress.com/201...l-source-code/

Ein weiteres Beispiel für den Einsatz mit GitHub Accounts:

GitHub API access with OAuth 2.0 authorization for web applications
https://mikejustin.wordpress.com/201...-applications/

Für erste Schritte kann es sicher verwendet werden. Beide Beispiele habe ich allerdings seit einiger Zeit nicht mehr getestet, Änderungen an den Anbieter-APIs kann es natürlich gegeben haben.
Auf die allgemeinen Sicherheitsrisiken sei verwiesen. Sicherer wäre ein regulärer (singulärer) Webserver, der dann als einziger die Application ID / Secret-IDs kennt und unter Kontrolle des Anwendungs-Anbieters ist. Sobald man diese mit einer clientseitigen Anwendung herausgibt, wird zum Beispiel das Zurückziehen des Zugriffs schwerer.

[Ulf346C]

Zitat von EarlyBird:

Zitat von Ulf346C:

nun, mit Azure AD und neuer Domäne, nicht mehr (die Protokolle sind alle freigegeben, hilft aber nichts)

Mit dem APP Kennwort funktioniert es nicht?
Das klappt bei uns problemlos

ic habe gerade herausgefunden: es liegt an dem "Plan" den der Benutzer hat.
Mit zum Beispiel "Exchange Online" kann man gar keine App Kennwörter vergeben.
Mein Administrator-Plan zum Beispiel kann das (- das Postfach benutze ich aber garnicht)