Allow certain email addresses to login via google in identity server - identityserver3

I would like to use identity server 3 with Google authentication to allow login from users with certain email addresses.
I can extract the email address from the claims in the OnAuthenticated method (GoogleOAuth2AuthenticationOptions.Provider.OnAuthenticated).
I would then like to reject the login if the email address is not in a list of specific addresses.
I have tried implementing IAuthenticationSessionValidator, but I do not have an email claim there.
I have also tried CookieAuthenticationOptions.Provider.OnValidateIdentity, but no email claim there either.
How should I perform such an email authentication check with identity server 3 and Google provider?

I found the solution, I had to add scope 'email' in OpenIdConnectAuthenticationOptions.

Related

How to setup noreply#<domain> google Cloud Composer?

I am trying to use sendGrid with Google Cloud Composer and providing SENDGRID_MAIL_FROM value noreply-composer#domain (noreply-composer#gmail.com), while running the airflow dag receiving error 403: Forbidden
. I did some research and got to know that from should be verified in the sender list. But if I just want to send alert mail with noreply user, this username physically doesn't exist and can not be verified.
Does anybody know workaround for the same, so I can send the mail with noreply username?
Elaborating more to my comment, according to SendGrid documentation pages, each sender identity should be verified using either Domain Authentication or Single Sender Verification. Based on the intro of Single Sender Verification as of most common use case restriction:
You can send only from the address you verify rather than any address
on an authenticated domain.
With said this, you might have to validate email account ownership for each FROM email address entry.
Domain Authentication will probably help to overcome the above mentioned limitation, however it requires to edit DNS records of the domain provider name resolution service:
You can send from any email address on your authenticated domain.
After adding CNAME, TEXT or MX particular records to your DNS service, they need to be validated in SendGrid UI.
I encourage you to check out the relevant tutorial to give more essential outcome.

Should I verify email addresses of Google Sign In users?

I am implementing an email verification service, with the purpose of confirming that the person registering is indeed the owner of that email address (specifically, that they work at the organisation that the email domain belongs to).
I will send an email post-registration with a single-use link in it that will set their status to verified = 1.
Users can choose to register and log-in using either a simple email/password combination, or by using the Google Sign In service.
My question is: do I need to verify the ones that have registered with Google Sign In? In order to provide their email address to me, they had to sign in with Google, who then confirmed the address. Is there anything I've missed here, or can I immediately consider these users to be the verified owners of these addresses?
If you are using google sign in there is no need to verify the user.
Whereas if have your own login system, then you must verify the email because
if the email is not verified then you cannot have forgotten password feature through email
and also the user might not have actually had the email so anyone else could create the same email and if you have forgotten password through email someone else could easily access others data.

Proper Way to Programatically Send Mail Using Google Apps

I have a domain which uses Google Apps for Business to handle email. I already have it mostly set up--MX records point to the correct location and my domain is verified.
I'm now writing a python app (with Django) that will need to serve mail from my domain. What's the correct way to do this with Google? Should I create a Google Apps "user" for the organization as a whole, and then authenticate via SMTP as that user and send mail from there?
The Gmail API says that it
is the best choice for authorized access to a user's Gmail data.
and that
Automated or programmatic message sending
is a typical use case. However, I'm not trying to access a user's data or send mail on behalf of a user, but on behalf of my domain. What's the correct way to proceed?
Any help much appreciated!
You could use SMTP or the Gmail API based on your description. In both cases, you'll need some sort of service account to send mail from. With SMTP, as you mentioned, you'll be authorizing via the instructions you linked.
If you choose to use the Gmail API route, you'll be authorizing the API usage with the account. The Gmail API has many other use cases (e.g. to access user's data) but you're only using it to send emails on behalf of a service account you control.

Intuit Open authentication and email addresses

At http://docs.developer.intuit.com/0025_Intuit_Anywhere/0010_Getting_Started/0030_Integrate_your_app/0030_Signing_Into_and_out_of_Intuit_From_Within_Your_App/Sign-in/Implement_SSO_and_OpenID_in_Your_App
it says the following:
"Intuit does not verify the user email address associated with the user's OpenID account. Therefore, do not use the email address for authentication and do not link user accounts based on email address."
What does it mean "do not use the email address for authentication"? I mean, isn't the user already authenticated, through OpenId.
Also it says that the user email address is not verified. But what if my app needs to send an email to a user that has logged through OpenId. How can I be sure the user will actually get the email? What is the recommended pattern to handle that?
Thanks
EDIT: also, can I use the email to uniquely identify a user, and if not, what should I use to uniquely identify a user from the open id response?
EDIT 2: also, is the developer charged when a user logs in with open id and the 36 day trial expires? Or is it just when using the "Connect to quickbooks" that the developer is charged, in which case, open id authentication itself is free?
Clement,
It means when a customer goes to the Intuit Appcenter and creates an account the email is not verified immediately, so you cannot single sign on a user based only on their email address if they already have an account in your system. You need to prompt them to login one time to map the two accounts.
If they are completely new then you can auto provision an account on your side and single sign them in, if you require the customer to verify their email address then you can send them a verification email.
thanks
Jarred

Single account for multiple OAuth providers (Facebook, Google, Windows Live)?

I have a web application that allows registration and authentication through Facebook, Google and Windows Live. Each OAuth request has the required scope to retrieve associated e-mail addresses from the authentication provider.
The current situation is that an account is created based on the provider and the provided identifier. This means that if a user has logged in with multiple providers the user will have multiple accounts on the web application.
I want to have the ideal situation of having a single acccount even when using multiple providers. I was thinking about using the e-mail addresses to see if an account exists for the user. If it exists, use the account based on the e-mail address.
How safe/reliable is this? Do all OAuth providers mentioned validate e-mail addresses? Better ways?
EDIT: Ran a tests and came up with this. Still looking for further advice :)
FaceBook: Cannot authenticate with unvalidated e-mail. Additional e-mail will not appear until validated.
Google: Provides `verified_email`. Additional e-mail will not appear until validated.
Windows Live: Cannot authenticate with unvalidated e-mail. Additional e-mail will not appear until validated.
Interesting question. You could try to use e-mail to check if user exists, but the problem is, user could be using different e-mail addresses for different providers.
My suggestion would be asking user (once he/she logs into your application using one of the methods) to attach other providers to to this account, so he/she can use them as well to log into your application.
It doesn't completely solve your problem (I'm not sure if solution exists), but user will have more control that way and you'll reduce the amount of accounts per user.