Is there a way for me to bypass the need to use OAuth for me to send out emails using the G-Suite platform in my application
I am still able to send out using the Microsoft 365 platform but some of my clients will not move to 365 and prefer G-Suite
You can use a service account. You will need to have the admin of the domain configure domain wide delegation to an account on the domain.
Once delegation is configured you can then use your code to impersonate a user on the domain and send emails on their behalf. This is what i normally do with sa a system designed for sending email conversation mails. When a user creates a new account the system could send an email conformation email. On behalf of say noreply#yourdomain.com
Your issue is going to be with the fact that your clients are the ones who own the domain so your going to have to get the google workspace admin for your client to set this up for you.
The other option would be to use standard oauth2 and authorize a user on the domain and send emails on their behalf.
The issue with that is going to be your application will need to be verified with one of the highest protected scopes. Your app will need to go though a security audit before it is verified. Last I checked that audit will cost you $15k-75k
Related
I'm building a daemon service (no user interaction) which needs to send a mail via MS Graph. I've registered an app in Azure AD and given it the User.Read.All and Mail.Send application permissions and given admin consent for those.
In my Java code, I'm using the ClientSecretCredentialBuilder for authentication. By doing
graphServiceClient.users("johndoe#mytenant.com").sendMail(params).buildRequest().post();
I can send an email on behalf of John Doe. However, technically, I could send an email on behalf of any user in this tenant. Is there a way to configure the app so that it can only use a specific account to send mail from?
Graph API doesn't yet support such a feature.
In my application, I want to use (oAuth based) Gmail API for sending Emails.
NOTE: I want to make my app public. A user can simply authenticate using the consent screen and will give the Email sending permissions to the application.
The question is that I am not sure if the verification of my app using OAuth based Gmail API will also include security assessment (costing $15k - $75k) or it will be verified without the security assessment.
The following scope
https://www.googleapis.com/auth/gmail.send Send email on your behalf
Is one of the Gmail scopes because of that it is considered to be a sensitive scope and when your application goes though the Google Oauth verification process you will need to have a third party company (provided by Google) to preform a security assessment on your application, they will probably need to see videos of your application in action and may or may not want to test it live and see code.
The cost for this is $15k - $75k.
Background
We have created a web portal which our CUSTOMERS can use to host content for their users. Authentication is done through a login page where a CUSTOMER's user enters their email and address and password. Note: Our CUSTOMERS manages these emails. The portal works really well and serves our CUSTOMERS' needs really well. What they need now is the ability to allow our CUSTOMER to enable SSO from their website to our portal. They already know the email address of the user, as it's their customer or supplier. We are looking for the safest and easiest way to do this.
Our tech stack
It's all built on Azure and at the moment we are using ASP.NET MVC and SQL Server. Ideally, we would like to stick to this stack but we are open to any other suggestions. The website is SSL encrypted.
What I was thinking
Add Azure functions to enable a REST API. Give the CUSTOMER a unique API Key which they can use to request a unique "authenitcation_Key" from our API. The "authentication_key" should expire after 60 minutes and is unique for every CUSTOMER/user combination. When the already authenticated CUSTOMER's user clicks on the link/button to go from the CUSTOMER's website to our portal, the website gets a new "authenitcation_key" and adds it to the HTTP Header for us to consume and validate.
What are the major security concerns/risks to this approach? How can it easily be improved?
The one which you thinking to implement will take lots of time and security tests, why not to use industry proven solutions.
I would suggest you to use IdentityServer4, you easily configure this according to your need. I know you are using .NET full framework, but this will not stop you using IdentityServer4 which uses .NET Core.
Check here https://github.com/IdentityServer/IdentityServer4/
If your stack is on Azure, you may just set up an AZURE OpenID Connect server. Your CUSTOMER application can be registered as Openid Connect (or OAuth) client, each request can then send a JWT access_token to your portal, and your portal verify and accept JWT as authentication token.
I am building a web application for a client and logging in with Office 365 is a requirement for the client. I am having a difficult time deciphering what exactly I need to do to make it so that only users with an email address belonging to their Office 365 organization can authenticate with my app using oAuth.
Is there a way to do this? Or am I going to have to implement the AD 1.0 endpoints? Being able to pull the users' groups and other enterprise-related data would be great but for simplicity's sake, all I really need to do is verify that they are apart of an organization.
How would I do this using the AD 2.0 endpoints?
The tenant id (tid) claim in the identity token would identify which organization (tenant) they belong to. But even easier than just checking the tid for every user would be to use the tenant-specific logon URL. So instead of the /common/oauth2/v2.0/authorize endpoint, use /<tenantid>/oauth2/v2.0/authorize.
I am working on a REST API that will be used by a number of clients in different organizations. To be more specific, a client application in an organization will connect to the REST API to exchange information. Multiple users can use this client application. Authentication should be handled by the client application in a way that there is not interaction with the user.
How can this be achieved with Azure Active Directory taking into account that:
I only would like to create one AD user account per organization and not per user in that organization.
A user of the client application should not be aware he is talking to my API, hence he should not authenticate.
The client application should authenticate with the AD account that was provided to the organization.
When an incoming call is received through the REST API, I should be able to identify the calling party.
The examples that are outlined here: https://azure.microsoft.com/nl-nl/documentation/articles/active-directory-code-samples/ never completely cover this scenario:
In the daemon example there is no user interaction, but then I should create a key (secret) for every organization. This seems quite complicated to handle.
In the other scenarios there is always user interaction.
Authenticating with a username and password without user interaction is only supported in .NET: http://www.cloudidentity.com/blog/2014/07/08/using-adal-net-to-authenticate-users-via-usernamepassword/
Any guidance in pointing me to the right direction would be highly appreciated!
I think the question misunderstands the daemon model. In AAD, you create a single application with a single key and then a service principal is created per organization. You only need one key - and you can identify the calling organization by looking at the tid claim in the access token.