I have a web application that currently sends automated password reset emails from a "no-reply" style email address in a gsuite domain. It currently works with simply a username and password over SMTP (with TLS), however, to get that working the GSuite Admin (who is not me) had to enable LSAs.
As I'm sure most are aware, Google is phasing that out over the next year, so going forward I'll have to use OAuth2 with the Gmail API (I think). I'm pretty new to this, so forgive my ignorance, but while I have successfully figured out how to send emails on behalf of a user (whereby the user needs to grant authorization to do so), I haven't figured out how to send emails on behalf of an automated account where there won't be someone to grant that authorization each time.
Based on my reading, it sounds like this needs to be set up as a service account with "domain wide delegation" granted by the GSuite Admin. However, if my understanding is correct, this would grant that service account access to send emails on behalf of ALL users in that domain, and not just the single email account I'd like to use. Is that correct? Is there a way to limit the access to individual accounts? (I suspect the admin will be nervous about doing that). Or am I completely on the wrong page as to how to proceed here?
Not sure if it really matters, but my current solution is implemented in PHP.
Any advice would be appreciated,
Thanks
I will give you some good news and other ones not so good.
1) Good news
The good news is you are on the right page about all the research you have made about service accounts and yes, you have to set domain wide delegation because the service account is a bot, which needs to impersonate a real person in order to send emails in his/her behave.
2) Bad news
The bad news is for the moment you can't restrict the users you would like to impersonate in your domain using the domain wide delegation. You would have to apply your own logic in your backend, which would do some kind of security process before the service account would impersonate that user. Let's hope Google in the future can add the feature of restricting certain users in a domain.
Aditional info
Just in case, you still don't know how to impersonate a user with a service account using PHP. Here it's a small example:
// Path to the service account json file
putenv('GOOGLE_APPLICATION_CREDENTIALS=/path/to/service_account.json');
// User to impersonate
$user = "email#domain";
$client = new Google_Client();
$client->useApplicationDefaultCredentials();
$client->setApplicationName("My app name");
$client->setScopes(Google_Service_Gmail::MAIL_GOOGLE_COM);
$client->setSubject($user); // Set the user to impersonate;
// Construct the service object.
$service = new Google_Service_Gmail($client);
Related
We want to send email to logged in users in our Drupal application. We are authenticating using AAD and our site is hosted in Azure app service.
we have a generic service account with a mailbox attached and we would like to notify the logged in users in case of any event using MS graph API and O365 connections.
Can we please get some guidance in this respect.
You can use the Graph API to send emails from your service account. Where you are going to have a problem is with identifying logged in users. An AAD token will be valid for your site even if the user originally signed in somewhere else, so logging signins isn't foolproof. Unless your users specifically sign out, the token will also be valid past when they stop using the site.
If you wanted to go down this road, then doing some logging of user actions and then sending the email to users that have been active within X amount of time might be an option.
If your goal is to notify users and you don't need an email specifically, then you might want to looking into using websockets or something similar to send notifications to the users within their browser.
I am planning to allow users to login to my website using oAuth authentication. I have a doubt whether I can completly rely on the email returned from the response to link the users to actual user account in my website. Can there be any security issue with this?
The most immediate, is that you must absolutely trust the oAuth provider. It might lie to you and take over your local user account.
For example, if the oAuth provider does not validate the user email, someone might register an account there with someone else's email, then login to your site taking over the local user account.
Also make absolutely sure you're using SSL.
I've implemented Google OAuth 2.0 login on a site that I'm working on. It works fine, except in situations when the user is logged with two or more different accounts on the same browser. It's asking him to choose which one he want's to use. But it's asking the user every time to choose the account. Is there a way to remember this, so the user can choose the account only the first time and later automatically to log him with that account?
You can put hd=domain.com parameter in the request to Google, but that only helps if the two logged accounts are from different domains and it can than log the user in with #domain.com account.
I read somewhere that you can send user_id account as a parameter to Google (I guess that would be the email address), but in this case I don't know the users email address before he logs in.
I think this behavior is the same if you use OpenID.
I'm using Google's PHP OAuth library.
Thanks,
Andrej
Google should have a cookie set that enables OAuth applications to tell what account to currently use.
If you know the email address you want to log in with, you can use the login_hint parameter and they won't see the account chooser. See https://developers.google.com/accounts/docs/OAuth2Login#sendauthrequest
Correct me if I'm wrong:
With respect to a user's email address associated with their account...
You can ask for and receive email addresses from openID providers (i.e. Google, Yahoo!, AOL, etc.).
You cannot obtain email addresses from OAuth providers (i.e. Twitter, LinkedIn, etc.).
You can receive email addresses from Facebook via OAuth.
If I am wrong and there is a way to obtain email address via OAuth, please describe an easy method.
Well what you have described is almost right.It dependents upon what you want both protocols Oauth and Open-id provides a way to Authentication but Oauth provides a fine grained control.
basically you can get Email address from Google/Yahoo/Window Live using Oauth and as per your analysis Both Twitter and LinkedIn model do not have the option to give back email.associated with the user.
But you need to have a clear understanding of whats different between both of them as that will clear your case what is provided by way
Both work on domain of security, identity, and authorization.
work on the principal of decentralization.
With Open ID, there is no suggestion of two web apps sharing your data. Except in the very limited sense that the Open ID provider may hold some general information about you.but this is data of a generic.
OAuth lets you authorise one website – the consumer – to access your data from another website
In short OpenId is coarse-grained while OAuth is more fine-grained.Oauth proicde a level of security by asking use to provide access to your data to the party who is asking the access and now its in the hand of user to allow or deny while with Open_id generic data will be available.
So choice is all yours.
I've got Oauth support in place for an app I'm working on. What I'm trying to work through is the logic for associating Oauth accounts.
Example:
Let's say a user has logged in before. They authenticated using Facebook. I now have an email address which I can safely assume will always be unique to that user. However, Twitter does not provide email addresses through its Oauth implementation, so if someone signs in with Twitter, and then Facebook, how do I correctly associate their account? I can't use user name, or handler, because obviously that could vary per provider. Is there any other way I could do this?
Do I require the user to enter their email address if they use an Oauth provider which omits it? I'm trying to put together the best user experience and the most stable system - so your help is highly appreciated.
If you're looking at working with multiple identity providers then your best solution would be to use an internal ID unique to your system and then associate the external accounts with that ID when the external authentication takes place. Additionally users in FB can change their primary email address so it would be safe to assume it's unique it's probably not safe to assume that it's current.