Is there a better way to do this? Azure / O365 / MS Graph: Anyway to use a personal or private school/work account with client secret?

soup

Smack-Fu Master, in training
54
Basically I have C++ process that does some work but if it fails I want it to send an email. SMTP/POP3 is not really an option. I want to use an O365 account.

Is there a way to use a client secret and get a token for a personal delegated process with a single school/work/personal account? With azure and a work account, I do not want to give the app access to all the users in the org either, just one account. I find if I use the auth flow (https://login.microsoftonline.com/common/oauth2/v2.0/authorize) during the process it returns a url that requires javascript and sometimes requires user interaction (need to login with browser). Is there a way to avoid user interaction and just keep using something like a client secret with an individual school/personal account to get tokens after I have consent to give the application permissions to send email?

I have been able to successfully send an email through https://graph.microsoft.com/v1.0/me/sendMail but the auth part of it requires user browser interaction including javascript.

So far it uses the Poco library that starts a micro C++ web server listening on a local port, launches edge with --user-data-dir="<my app's edge directory>" and localhost as the app redirect as an auth parameter, then once the auth code is received by the C++ web server it closes edge and sends the email. However, after the O365 login cookie expires this will not work, it will require password.

I read all the Azure docs I could find on oauth2 auth, and tokens, and feel like I am drowning in a sea of information and have not found a way around this yet.

Edit: I read something about incorporating Microsoft Web Edge View 2 instead of launching "Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe", maybe I could toss in the username and password in the fields and submit, but I would prefer a simpler way just to use a client secret.
Edit2: I could see Microsoft having some javascript security to make sure it is not a non-human logging in to account and prevent this scenario.

 
Last edited:

SplatMan_DK

Ars Tribunus Angusticlavius
7,794
Subscriptor++
Basically I have C++ process that does some work but if it fails I want it to send an email. SMTP/POP3 is not really an option. I want to use an O365 account.

Is there a way to use a client secret and get a token for a personal delegated process with a single school/work/personal account? With azure and a work account, I do not want to give the app access to all the users in the org either, just one account. I find if I use the auth flow (https://login.microsoftonline.com/common/oauth2/v2.0/authorize) during the process it returns a url that requires javascript and sometimes requires user interaction (need to login with browser). Is there a way to avoid user interaction and just keep using something like a client secret with an individual school/personal account to get tokens after I have consent to give the application permissions to send email?

I have been able to successfully send an email through https://graph.microsoft.com/v1.0/me/sendMail but the auth part of it requires user browser interaction including javascript.

So far it uses the Poco library that starts a micro C++ web server listening on a local port, launches edge with --user-data-dir="<my app's edge directory>" and localhost as the app redirect as an auth parameter, then once the auth code is received by the C++ web server it closes edge and sends the email. However, after the O365 login cookie expires this will not work, it will require password.

I read all the Azure docs I could find on oauth2 auth, and tokens, and feel like I am drowning in a sea of information and have not found a way around this yet.

Edit: I read something about incorporating Microsoft Web Edge View 2 instead of launching "Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe", maybe I could toss in the username and password in the fields and submit, but I would prefer a simpler way just to use a client secret.
Edit2: I could see Microsoft having some javascript security to make sure it is not a non-human logging in to account and prevent this scenario.


You can create a custom app that interacts with your tenant and deploy it to Azure. Depending on your needs it can be a container instance (cheap) or an allways-on app service (less cheap).

If you deploy a custom app, you can authorize it to interact with the rest of the tenant using whatever credentials you want (service principal). Then use whatever method you like to interact with your service; web API, RPC, MQTT, or whatever.

But frankly, this seems like an awful lot of trouble to go through. What is the purpose? What are you trying to achieve?
 

soup

Smack-Fu Master, in training
54
You can create a custom app that interacts with your tenant and deploy it to Azure. Depending on your needs it can be a container instance (cheap) or an allways-on app service (less cheap).

If you deploy a custom app, you can authorize it to interact with the rest of the tenant using whatever credentials you want (service principal). Then use whatever method you like to interact with your service; web API, RPC, MQTT, or whatever.

But frankly, this seems like an awful lot of trouble to go through. What is the purpose? What are you trying to achieve?
Sorry for getting back to you so late. Basically I just want to send an email notification that a process failed. Paying just to send from an O365 account is overkill, I'm just going to use SMTP through gmail.
 

oikjn

Ars Scholae Palatinae
969
Subscriptor++
will the emails go only internally? If so, and you have a static internet IP, you can send emails without authentication at all. This is "option two" on the link below. This is what we do internally for all reporting devices since its free and they don't need any account, but they can only send to internal recipients. We then use things like deviceXYZ@contoso.com or MFP1@contoso.com as the sender and then it can send to any user@contoso.com or any other M365 domain controlled by you such as user@contoso.net .

Three Options Per MS