Indy und OAuth / Microsoft365

[haentschman]

Hallöle...

Aus Microsoft Entra (früher Azure) Admin Center. Anmelden, vorzugsweise Admin für Alle, App definieren und dann hast du die zugehörigen ID. Dann mußt du dich durchkämpfen. Besonders mit den Zugriffsrechten...

PS: Wenn du die Zugangsdaten dem Programm mitgeben mußt...sicher verschlüsseln! Nicht im Klartext in die INI...

[swestner]

OK, danke.

Das beantwortet Teil 1 meiner Frage.

Die Daten für das OAUTH dienen also dazu, mich generell gegenüber dem Webservice zu authentifizieren.

Beim Senden über Indy gebe ich dann ja aber einen Username an und den OAUTH-Key. Dieser ist aber nicht userbezogen. Wie wird dann der Benutzer authentifiziert?

[Thomasl]

Hier ein Testprogramm von mir ohne ClientID (Stand 2022 mit 'code_challenge_method', 'S256')
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx mit dem eigenem ersetzen

Mit dem AccessToken wird die E-mail Versendet
Mit dem RefrehToken bekommt man den neuen AccessToken

Achtung, da werden die Token als Klartext ausgegeben

[swestner]

Sehe ich das richtig, daß der ClientSecret nicht benötigt wird?

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?

[Thomasl]

ClientSecret wird bei Google verwendet, bei Microsoft nicht

[Sinspin]

Setup der Einstellungen und Rechte hat uns zwei Monate gekostet.
Wenn passend eingerichtet könnte jeder Nutzer von jedem Account senden. Per default geht das aber nicht.
Du musst ein Sender Account angeben für das eine Autorisierung von einem Admin gegeben wurde.
Das passiert beim ersten Versuch ein OAuth durchzuführen. M$ merkt sich das. Dafür öffnet sich im Browser eine Website in der sich der Admin identifizieren muss.

Wenn du "ClientCredentials" als Grand Type verwendest ist später nur das AccessToken relevant. Die Authorisierung via WebPage kommt damit nicht erneut und Du musst kein AuthRefreshToken speichern.

Wir verwenden NSoftware für den Zugriff. Wie immer ein Genuss.

[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.

[Thomasl]

Zitat von swestner:

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

Das kann doch nicht sein, oder?

Damit man den Token bekommt, gibt man doch im Browser die E-Mail,Passwort und 2Faktor etc. ein, und bekommt für diesen Benutzer einen RefreshToken

Der AccessToken kann auch mal 1000 Zeichen lang sein, da steht dann wohl alles mit drin was der Benutzer darf?

[Bbommel]

Zitat von swestner:

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.