Indy und OAuth / Microsoft365

[Thomasl]

Die WebPage kommt immer nur 1x bei der ersten Anmeldung, danach benötigt man das nicht mehr.

Bevor man sowas wie NSoftware verwendet, dann kann man auch das Beispielprojekt von Microsoft über eine Comserver DLL einbinden.

[Bbommel]

Zitat:

Zitat von swestner (Beitrag 1549890)

Und weiterhin meine Frage zu dem Thema, das ich immer noch nicht verstanden habe:
Das Token ist meine Berechtigung, überhaupt Mails zu versenden.
Bei Der Authentifizierung mittels INdy übergebe ich dann die Mail des Benutezrs und das Token.

Das Toekn ist aber nicht userabhängig, also kann ich jeden beliebigen User (E-Mail-Postfach) angeben.

Das kann doch nicht sein, oder?

In Microsoft Entra erstellst für eine Anwendung - einen Client, identifiziert durch seine Client-ID - den Zugriff auf einen bestimmten Dienst, in dem Fall auf die Mails. Was genau dieser Client dann darf, ergibt sich entweder aus dem gewählten OAuth-Authentifizierungsverfahren und/oder aus weiteren Details, die du innerhalb des Dienstes konfigurieren kannst. Bei Micorosft sind die Begriffe normalerweise "Delegierte Berechtigungen", dann muss sich ein konkreter Benutzer interaktiv anmelden, um ein Token zu bekommen und die Berechtigungen, die er im eigentlichen Dienst hat, ergeben sich dann unmittelbar aus seinen Berechtigungen, die er auch sonst dort hat, also wenn er selbst sich direkt in seine Mails einloggen würde. Alternativ dazu gibt es noch die "Anwendungsberechtigung", welche ohne Bnutzerinteraktion auskommt und für Dienste gedacht ist, die im Hintergrund zusammenarbeiten sollen. In dem Fall muss du innerhalb des Dienstes konfigurieren, welche Berechtigung die Client-ID haben soll - also beispielsweise: die Client-ID 4711 hat Zugriff auf den Mail-Account [e-mail].

Wenn du das Token einmal hast, dann sind damit dann ja diese konkreten Berechtigungen verbunden. Je nachdem, wie das Token konkret umgesetzt ist, stehen dann z.B. Client-ID oder auch ein Benutzername im Token selbst (schau mal nach "JSON Web Token"), sodass der Dienst weiß, was er mit deinem Token anfangen soll und worauf er dir Zugriff geben darf oder eben nicht.

Hier könntest du dich z.B. in die Details reinsteigern: https://learn.microsoft.com/en-us/en.../access-tokens

Vielleicht klärt das ja noch ein paar Fragezeichen.

[Sinspin]

Zitat:

Zitat von Thomasl (Beitrag 1549907)

Bevor man sowas wie NSoftware verwendet, dann kann man auch das Beispielprojekt von Microsoft über eine Comserver DLL einbinden.

Absolut! Nur für einen Anwendungsfall ist NSoftware auch ein bisschen teuer. Aber wir nutzen es für zig verschiedene Schnittstellen, da wir als Inhaber einer Red Carpet License mit allem verwöhnt werden was zur Verfügung steht.

[Klausi]

Mit dem Code von friedt99 aus 2023 erhalte ich keinen gültigen Accesstoken. Hat jemand einen Tipp was da falsch läuft?
Oder kann mir Thomasl seinen Quellcode für das Testprogramm schicken?

[Bernhard Geyer]

Zitat:

Zitat von Sinspin (Beitrag 1549917)

Zitat:

Zitat von Thomasl (Beitrag 1549907)

Bevor man sowas wie NSoftware verwendet, dann kann man auch das Beispielprojekt von Microsoft über eine Comserver DLL einbinden.

Absolut! Nur für einen Anwendungsfall ist NSoftware auch ein bisschen teuer. Aber wir nutzen es für zig verschiedene Schnittstellen, da wir als Inhaber einer Red Carpet License mit allem verwöhnt werden was zur Verfügung steht.

Haben hier auch NSoftware.
Ist halt ein abwägen - Selbst machen und x Tage investieren und immer wider "Nachjustieren" müssen oder x € jedes Jahr an NSoftware überweisen.

[mjustin]

Zitat:

Zitat von Klausi (Beitrag 1550707)

Mit dem Code von friedt99 aus 2023 erhalte ich keinen gültigen Accesstoken. Hat jemand einen Tipp was da falsch läuft?

Was bedeutet denn nicht gültig, kommt eine Fehlermeldung?
Sind die Mail-Benutzer im https://admin.microsoft.com/Adminportal angelegt?

[Redeemer]

Der Access Token ist nun wirklich extrem einfach zu besorgen und hier das geringste Übel. Das ist einfach nur ein POST-Request mit vier Formularfeldern als "application/x-www-form-urlencoded". Statt als Felder kann man auch einen Querystring als Roh-Payload übergeben (client_id=bla&client_secret=...), was technisch dasselbe ist. Das klappt auch in Delphi, hier aber zur besseren Sichtbarkeit in SoapUI:

[mjustin]

Zitat:

Zitat von Klausi (Beitrag 1550707)

Mit dem Code von friedt99 aus 2023 erhalte ich keinen gültigen Accesstoken. Hat jemand einen Tipp was da falsch läuft?
Oder kann mir Thomasl seinen Quellcode für das Testprogramm schicken?

Der Code von friedt99 ist soweit korrekt. Er implementiert den "OAuth2 client credentials grant flow" bei dem client id und client secret benutzt werden.
Das Problem wird bei der Konfiguration der App-Registrierung oder der Exchange Online Konfiguration liegen. Die Referenz, die ich verwendet habe ist hier:
https://learn.microsoft.com/en-us/ex...by-using-oauth
Hier vor allem die Abschnitte "Add the POP, IMAP, or SMTP permissions to your Microsoft Entra application" und "Register service principals in Exchange".

[mjustin]

Zitat:

Zitat von Redeemer (Beitrag 1550712)

Der Access Token ist nun wirklich extrem einfach zu besorgen und hier das geringste Übel. Das ist einfach nur ein POST-Request mit vier Formularfeldern als "application/x-www-form-urlencoded".

Das ist aber auch der einfachste Flow, der "OAuth2 client credentials grant flow". Dieser Flow ist nicht geeignet für public clients, bei denen das client secret nicht in der Anwendung gespeichert werden darf. Das kann man zwar machen, aber wenn das client secret kompromittiert ist, muss es auf allen Benutzer/Kunden-Systemen durch ein neues ersetzt werden.
Für public clients existiert der aufwendigere "OAuth2 authorization code flow" mit Callback-URL, bei dem kein client secret notwendig ist (ausser bei Web-Anwendungen, aber da liegt das client secret zentral beim Anbieter auf dem Server).
https://learn.microsoft.com/en-us/ex...by-using-oauth