Develop Reference

Authenticate an EWS application by using OAuth with Permission control

I want to have a windows service that can received unread mail from my O365 account every 3 minutes and have different action depends on Mail subject. I choose EWS managed API instead of Graph is because maybe I would use this program on Exchange Server in the future. I'm following this tutorial Authenticate an EWS application by using OAuth and I have some question about permission control, in this case I use Application permissions which run without a signed-in user present. for example, apps that run as background services or daemons and can access multiple mailboxes.
Now I can access my mailbox with the applicationID, tennatID and Client-secret. But I have to inpersonate someone within my tennat(domain) and than I can send mail by the Mail Account. My question is Is it have any permission control can set that this application only can access or inpersonate part of tennat user rather than all user within my tennat? (in Azure AD Api permission setting I only seen full_access_as_app - Allows the app to have full access via Exchange Web Services to all mailboxes without a signed-in user.) I think its not make sense if this application have permission that can impersonate ALL user of my organization, that would be a big deal if this application client-secret exposes.
Sorry for my poor English.

You can use Application access policies to scope your application so it only has access the mailboxes it needs. see https://learn.microsoft.com/en-gb/graph/auth-limit-mailbox-access.

Can you use an API account and Legacy Authentication for SOBO when the organization's users have SSO enabled?

While SSO is enabled for an organization, can an API account still use Legacy Authentication (username/password still being used for this account) on behalf of a user that has SSO enabled?
Our company wants to transition to using SSO for all user accounts (except possibly the API account). Currently, we use DocuSign's Legacy Authentication header (X-DocuSign-Authentication) to send envelopes on behalf of users and create sender views for them. Both of these actions involve using our API account's username and password for authentication on behalf of a user.
I've read this post that says:
If you're using Legacy Header authentication, your application won't
be able to authenticate as users who have SSO Login enforced. Until
you're able to implement one of the OAuth workflows, users who need to
use your API integration will need to have their Login Policy set to
allow them to login with a password.
Does this mean that any user account that will be sent on behalf of them will need to have SSO disabled while the Legacy Authentication header (and API account using username/password) is being used?
In addition, we are trying to avoid having every user separately authorize the application to act on their behalf. This post seems to mention there is a way to avoid that. Both the Authorization Code Grant and JWT Grant state that you must get your user's consent. We want to avoid this since we have 100's of members and staff additional staff added frequently.
Optimally, we would like to keep the API things as they are. If we can't or shouldn't, what changes do we have to make?

If SSO is enabled, a user can still authenticate via their DocuSign password, and thus Legacy Header auth will still work. If SSO Authentication is made mandatory via Login Policy settings, the user cannot authenticate with their DocuSign password, and Legacy Header auth will break.
If your authenticating "system sender" user has SSO optional, the SendOnBehalfOf header can be used to impersonate anyone on the account, regardless of the other user's Login Policy settings.
If you have a Claimed Domain, you can grant Admin consent so that all users with email addresses under that claimed domain (current and future) will not be required to grant individual consent for JWT impersonation. More information on that is available here: https://www.docusign.com/blog/developers/oauth-jwt-granting-consent

Sending email on behalf of another user

Currently I have used GMail API (OAuth Credential for Web) to read and send email messages. How can we send email on behalf of another user (i.e. noreply#example.com)?
In enterprise application, do we need to use service account for reading specific user's mail labels, messages and send email on behalf of that user?

Solution
Indeed you CAN send and read the mailbox of other user's in your domain with the Gmail API using a service account with domain wide delegation.
You will need to grant the service account with the Project Role of Owner using the domain wide authorization.
Apart from the official documentation linked above, here is a tutorial on how to send emails on behalf of other users using service accounts. To read from their mailbox you would follow the same process. Here is more information on mail delegation in case you are interested.
NOTE : in order to do this your service account must be in the same domain as the user's email you are trying to send and read messages from.
I hope this has helped you. Let me know if you need anything else or if you did not understood something. :)

Using Service User to upload files to Google Drive by email address

I am connecting to a service account using a service account credential.
I'm trying to scale this up to be used for multiple users within the same company. All users will have Google accounts managed by this company, and I will have a gsuite service account for the entire company. How can I upload a file to users personal Google Drive based on an email address using a gsuite service account?

You want to use ServiceAccountCredential, with a User property set to the appropriate user.
Assuming you're loading the credentials using GoogleCredential, this isn't too hard. For example:
GoogleCredential credential = Google.GetApplicationDefault()
.CreateScoped(...)
.CreateWithUser("foo#bar.com");
If you wanted to use the same original credentials for many different users, you could keep the result of CreateScoped(...) around, and just call CreateWithUser to create a new user-specific credential for each operation.

Using Oauth2 you are going to have to have each of the users authentication your application. This will give you access to their drive account directly. Now you say you have a master user. You could just request that these other users share a folder on their Google drive account with the master user then it will have access. Note you can't share the root directory.
You might want to consider using a service account instead of oauth2 this the users will then have to grant the service account access to their drive account.
Now if this is a gsuite users all of this can be automatically done useing domain wide delegation of the service account.

Here in my work we have the same scenario as you, and to be able to achive this type of integration we created a service account with wide domain delegation enabled for this account.
This way we can use the service account to access users data on their behalf.
But for that, when creating the service account credential, you must impersonate the service account credential passing the user email, this way you'll be able to access user data on their behalf using the service account.
Since you're using C#, I've created a small library that create service account credentials for any type of google api services and for both JSON or P12 credentials.
https://github.com/drodriguesaar/GoogleApiServiceFactory

Accessing Exchange Server using EWS - Admin rights required?

I am going to develop a module using Exchange Web Service Managed API 2.0.
I would like to know whether we need to have ADMIN level permission to access the EWS web service? Can any account, access the EWS service or it requires ADMIN rights?
I am asking this question because the code I am going to write is going to access the Exchange Server 2007 using EWS.

You need the login to the mailbox (usually primary SMTP and password), and that does not have to be an admin login.
There is also impersonation where you can login 'as another person'. You must then have the login information for the other and you must have impersonation permissions.
Finally, if user X shares his mailbox with Y, Y can login and access the mail from X. What he can do depends on the rights X gave him.