I have a windows service that imports support emails into a CRM from 4 different email accounts. I am currently using IMAP, but would like to move to Microsoft Graph.
After much investigating I am only seeing two options to make this happen:
Using a delegated permission: Implement a user interface to authenticate to the email accounts via OAuth (won't work for a daemon process)
Using an application permission: Get permission from my email admin to access ALL email messages in the company so I can process email from these four accounts (It will be a cold day in Hades when I get this kind of permission on a corporate level)
So, from what I can see, I am stuck. Can anyone recommend another option, or do I go back to IMAP?
With 2 you could scope the permissions so your application only has access to those four mailboxes in question https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access. For the corporate this would be the most secure option eg no user account/password or licence and you app is just restricted to email on those four account.
So, from what I can see, I am stuck. Can anyone recommend another option, or do I go back to IMAP?
In security terms even option 1 is generally going to be better the IMAP (especially using basic auth) and you can use it in a daemon if you use the ROPC grant https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc which is going to be the same as what you doing with IMAP.
Related
At work we have developed an individual customer specific software application that is in use for a long time. We have a new requirement in this same program to implement an option for sending emails directly from the program.
The user is able to add his own email account with the credentials and login through our program. For Microsoft and Gmail accounts OAUTH is implemented and something here is not very clear.
For Gmail-API we have made an OAUTH Client and Consent screen on Google Cloud Console which we need to publish and verify and here is where the problems start. I am not very clear with the whole process of verifying the app.
In the steps for verifying is stated that we should verify a domain for the app, but this software is not hosted anywhere on internet and is not publicly available, it is available to a number of specific users (2000-3000).
Also Google requires a YouTube video of the software to be available publicly, which we are not able to upload because of customer requirements. Also here is required a Data Protection Policy page for the application which we as a developers don't have because we are only developing the software.
Other thing that is not clear to me, how is this type of software rated by Google, internal or public?
Have anyone experience with this or something similar?
Verifying an app for one of the Gmail scopes is a very complicated process. This process depends upon which scope of authorization you are requesting of the users.
In your case you are trying to send an email so you are using the users.messages.send method from the Gmail api. This uses a restricted scope. Which means you will need to go though the full process.
First of it doesn't matter if your application is hosted or not. It also doesn't matter that you give this app to a limited number of users. What matters is the scopes you are using.
You will need to ensure that your domain has been registered via google search console. So this app will need a domain
Once that is done you will be able to host your website, and the privacy policy on that domain.
You will need to create a YouTube video showing your application running, and how authorization is used.
You will also need to submit to a third party security checkup of your application which is not free and will need to be done once a year.
All of this is needed because of your consent screen it doesn't matter if its hosted any where, It also doesn't matter if this is only available to specific number of users.
If all of the users are part of a single google workspace account, that has created your client id and client secrete then you can set the app to internal and you wont need to be verified. This only works for google workspace domain accounts.
I'm exploring accessing mail (and sending mail) on behalf of other users. I have read about the graph api which would allow me also to handle chat messages later on.
I wanted to start implementing this with my personal account (#outlook.com) and followed basically this tutorial: https://cmatskas.com/create-a-net-core-deamon-app-that-calls-msgraph-with-a-certificate/ (this seems to be the same as the walkthrough in the portal)
I found questions and answers (like Microsoft Graph to send mail with Client Credential Flow (application permission) and personal account) but I do want to create a daemon app which seems not to work with a personal account (which makes sense because I could read Microsoft's end user customers data).
Furthermore, when trying to create such an app there is the following warning:
If I would create a development env for this I am still now working at a verified publisher, so I cannot develop an application to see if it fits our needs?
It is possible to have a developer sandbox from Microsoft for that purpose.
See https://learn.microsoft.com/en-us/office/developer-program/microsoft-365-developer-program-get-started for information on this
I'm developing an application on Microsoft Graph that runs as a daemon, and needs access to many accounts. As a result, I'm using a service account, also known as client credentials (using this method).
I can request the proper scope (calendars.readwrite) however as far as I can see, I cannot restrict to which calendars I have access. In my case, I only need access to the meetingroom calendars, and I'm afraid that organisations will not allow my application if I can also read and write from/to the CEO's calendar.
Is there any way (either while creating the app, or during/after giving admin consent) to restrict my app to only a subset of calendars? Or should I approach this problem differently and (e.g.) not use a service account in the first place?
What is the best way to do this. I can not find a link. Almost every example is using OAuth2 and native app version of the examples still wants the client app to pop up a browser.
My system does not have a browser. I can make REST requests but that is it.
I just want to use a simple client that can list things on a command line app just by using Outlook.com or Hotmail account. Not for a Work/School account (no Active Directory).
Long story short I don't want to be redirected to a website. I can make http request and parse the response.
These are my limitations. All implementations are in C or c++. Are there an examples with flow diagram?
Technically what you're looking for is the client_credentials grant. You can read about setting this up # Get access without a user.
This grant has some limitations. In particular, it only supports Work/School Accounts. This is because your application will require the consent of an administrator, something not available with a personal Microsoft Account (Outlook.com, XBox Live, etc.). You'll need an Active Directory to authenticate against. You can however set up Azure Active Directory for free.
We are developing a web application using Microsoft Graph, where the signed in user can, Export all the calendar events to a third party calendar Application. After this initial export, we need to keep the exported data in sync with calendar changes via service app (a scheduled task running on server). This need to be a multi tenant application, as people from different organizations should be able to use this service.
Right now we did the authentication using OAuth 2.0 and OpenID Connect as described in this sample. Later we understood that the access token we get using this method cannot be used in the service app without user interaction. Considering our scenario what is the best way to achieve this?
I have read about App-only authorization method to do this. If we use this authentication method, the app need to be consented by a tenant administrator and the these applications are quite powerful in terms of what data they can access in the Office 365 organization. Considering we are developing a product used by different organizations, will it be feasible to use this method?
To use the client credentials OAuth2.0 flow (aka "App-only" or service account access depending on who's documentation you're reading) the admin for each tenancy will need to specify which scopes your daemon process can have for users in their tenancy. The end users can't give these scoping rights to your code themselves (as far as I know at least).
One thing to watch out for is that currently Graph API doesn't allow you to mess about with calendars that are attached to Office 365 Groups if you're using the client credentials flow. This is a pain for us, so we've raised it as an issue that needs fixing in the Office 365 feedback system. if that's an issue for you or anyone else, please throw a few votes at it so that it gets more attention at Microsoft. :-)