My organization is in the process of switching to Google Apps for Education. I have successfully used Google Email Uploader to migrate my emails (as an admin of the domain). However, when I attempt to upload another users email, I encounter the following error:
Username or password not accepted
This domain does not allow users to access the Email Migration API.
Error 403
API Access has been enabled in the User Settings for our domain. Does this take some time to activate? Are there other steps I must take prior to migration? Thanks.
Administrators of Google Apps for Business/EDU domains always have the ability to migrate mail. However in order for users to be able to migrate mail to their own account, it must be enabled in the Control Panel. See Google's instructions for enabling user email migration.
Related
How to send service emails
from my backend with smtp.google.com or Gmail API while making sure
the secret stored on the backend server can only be used to send emails from a specific sender?
Goal
send user account activation emails from my backend
use smtp.google.com or Gmail API (i.e. no own SMTP server)
authenticate with OAuth2.0 (i.e. don't enable "less secure apps")
Current state
implemented the email sending part
for testing, I created a noreply#**.** Google Suite account
for testing, I generated an accessToken via OAuth2 Playground
using the accessToken I can send emails via smtp.googl.com
Problem
Google suggests to use a service account for this
But to send emails from no-reply#x.y I have to enable Domain-wide Delegation
Domain-wide delegation allows to impersonate every domain account
the secret stored on the backend should only allow to send mails from no-reply#**.**
Lets start with send user account activation emails from my server I am gong to assume that you have a web app. This web app allows users to register with your system. Now when a user registers with your system you want to automatically send them an account creation email. Your idea is to use Google rather than setting up your own smtp server and sending these emails from your own system. Not a bad idea really.
Lets think about this for a minute the emails would need to be sent automatically so you need some kind of service sending them. To do that you want to use a service account. Again this is a great idea using a pre authorized service account that you will not need to have a user to authorize the app.
The only issue is that service accounts do not work with normal gmail accounts. To use a service account with Gmail api you need to use a google workspace domain account. The workspace domain admin would then be able to add permissions to the service account letting it act like a user on the domain. In this case your idea of no-reply.
So your workspace domain account would have a user called no-reply. The domain admin would then configure domain wide delegation to the service account allowing it to pretend that it is the user called no-reply. For all intents and purposes the service account is the no-reply user. It will be able to send mails as if they are coming from that user.
For all this to work you will need the workspace account with that user.
Have a look at the following link, it's actually one of Google's better examples it shows how to set up the delegation.
Perform Google Workspace Domain-Wide Delegation of Authority
Here you create a service account with credentials, allow this account to impersonate other users (e.g. the no-reply user), to only use the Gmail API and to only use it to send emails.
the documentation is a bit outdated, you can skip the step Grant users access to this service account and create the service account key afterwards via the service account edit function: Manage keys
in the step Domain wide delegation you need Google Admin not the Google Cloud Platform Admin Console as in the previous step
Just remember to swap out the lines about
https://www.googleapis.com/auth/admin.directory.user,
https://www.googleapis.com/auth/admin.directory.group
and use
https://www.googleapis.com/auth/gmail.send
instead as you want to access the Gmail API and only allow the service account to send (not read) emails
tip
in the sample code in that link
.setServiceAccountUser(userEmail)
userEmail is the email address of the user you want to impersonate in this case no-reply#x.y
So I guess what I am saying is that what you want to do is definitely possible, however, it may be easier just to set up your own SMTP server.
Suppose I have an application in which I have enabled (google) Oauth2 authentication but I want only a few business people can log in to my application with there specific email id and rest of the people can't. How Can we achieve this using Oauth2?
1.) Lots of people have a Google account and can authenticate with Google
2.) I want Only some of them should be authorized to use your app, which maybe deals with business assets
I suspect your requirement is:
Lots of people have a Google account and can authenticate with Google
Only some of them should be authorized to use your app, which maybe deals with corporate assets
In this case I would proceed something like this:
STEP 1: PREREQUISITE USER SETUP
Get a list of users and perform an Administrator Approval step to create them in your product database, perhaps with Name and Email fields.
STEP 2: INCLUDE THE EMAIL SCOPE DURING LOGINS
In the Google login redirect, use scope='openid email' so that you can identify the user via email after login. Allow users to successfully authenticate.
STEP 3: AFTER LOGIN PROCESS THE ACCESS TOKEN
You will then get then be able to get the user's email address from the access token (though you may have to send it to the Google User Info endpoint).
STEP 4: DENY ACCESS WHEN REQUIRED
If you can't find the email associated to the token in your product user data, present a Forbidden message to the user.
FURTHER INFO
See my User Data Write Up for further details on technical options. Note that I have not actually tested this with Google, but I have used the general approach with a few different systems.
We are integrating Google Calendar with our room booking system. Users in GSuite domain should login on our reservation screen and book a room. So far I made use of an service account with domain wide delegation to impersonate the users (the setSubject() method, passing the e-mail address of the impersonated user). Everything works, although this way we cannot verify if the user we want to impersonate is logged in successfully or not, the event will be just created with him as the organizer, because setSubject() only requires the email to work properly.
In IBM Domino, when using an Java XPage I was able to compare passwords of the user, not in plain text but there was a function which compared plain text with user's hashed password and returned true if they were equal.
As I see Google doesn't have such a thing if I'm right. How could I check if the user can successfully log in programmatically?
If you want to perform actions in Google Calendar on behalf of a currently logged-in user from a web browser, you might want to use OAuth2 for Web Server Applications instead of using a service account with impersonation.
I received this error when trying to authorize my app with my own account:
Your project is trying to access scopes that need to go through the verification process.
{invalid=https://www.googleapis.com/auth/contacts}
If you need to use one of these scopes, submit a verification request. Learn More
When I use a different account, the error message is different:
This app hasn’t been verified to access:
{invalid=https://www.googleapis.com/auth/contacts}
Are you the developer? If this project needs these scopes, sign in to an account with access to edit your project and try again.
If not, contact the developer for help.
As per the announcement on May 11, 2017, publicly available applications with access to certain user data must pass review. If you see an access error for your app, submit a request using our OAuth Developer Verification form.
For personal-use apps and those you are testing, join the Google group Risky Access Permissions By Unreviewed Apps, which allows you to approve data access for personal and testing accounts. See the Google API Services User Data Policy for more information.
UPDATE: Corrected broken link to form.
I am using both GAM and the Google API PHP client library to integrate with Google for Work.
I am using a service account and I have authorized the Client ID in the Admin console to access the following two scopes:
https://www.googleapis.com/auth/drive
https://apps-apis.google.com/a/feeds/emailsettings/2.0/
I have also enabled the Drive API and Admin SDK in the Developers Console. There is no Email Settings API that I can see.
I have followed this page and granted GAM access to all scopes during testing - which does include the Email Settings scope.
I can successfully use GAM and the PHP client library to access the Google Drive API. However, I always get a 403 - Unauthorised when trying to do any of the Email Settings API functions detailed in https://developers.google.com/admin-sdk/email-settings/
I am fairly confident that I have the authorised the right Client ID in the Admin Console. When I remove the scope https://www.googleapis.com/auth/drive from the Admin Console it blocks my access to Google Drive from both GAM and the PHP client library.
Any suggestions on what to try?
GAM does not use service accounts for email settings API, it uses standard OAuth 2.0 for installed apps. Be sure you used a super administrator to authorize GAM access to the email settings API. If you didn't, run
gam oauth revoke
And then another command like:
gam all users show imap
And this time make sure you are logged in as a super admin.
Jay's post led me to the answer - namely that I should be logged in as a super admin when accessing the Email Settings API.
I therefore created a super admin account and authenticated GAM using that. That gave GAM access.
In order to get the PHP client library working, I had to impersonate the super admin account when I created the OAuth2 token. The code to impersonate the admin account is below:
$credentials = new Google_Auth_AssertionCredentials(
$service_account_email,
$scopes,
$private_key,
'notasecret', // Default P12 password
'http://oauth.net/grant_type/jwt/1.0/bearer', // Default grant type
$admin_email
);
where
$service_account_email is the email address of the service account created in the Developer's console - not the super admin account.
$scopes is an array of the API URLs that you need to access
$private_key is the contents of the P12 certificate created from the Developer's console.
$admin_email is the email of the super admin account.
Hope this helps someone else.