google oauth2 impersonate service account with user@gmail.com

Question

I wanted to access some google api services:

• GDrive API
• Contact API
• People API

And I'm struggeling with the oauth2 impersonate service account flow (you know that one: Google Oauth v2 - service account description. For impersonification you need to apply the "Delegating domain-wide authority" in the google apps console, download the correspoding pk12 file and activate the api in a google console project.

At the moment I always get:

com.google.api.client.auth.oauth2.TokenResponseException: 401 Unauthorized
at com.google.api.client.auth.oauth2.TokenResponseException.from(TokenResponseException.java:105)
at com.google.api.client.auth.oauth2.TokenRequest.executeUnparsed(TokenRequest.java:287)
at com.google.api.client.auth.oauth2.TokenRequest.execute(TokenRequest.java:307)
at com.google.api.client.googleapis.auth.oauth2.GoogleCredential.executeRefreshToken(GoogleCredential.java:384)
at com.google.api.client.auth.oauth2.Credential.refreshToken(Credential.java:489)
at oauthsample.GDriveAPI.<init>(GDriveAPI.java:50)
at oauthsample.GDriveAPI.main(GDriveAPI.java:85)

Here is my code:

        HttpTransport httpTransport = new NetHttpTransport();
        JacksonFactory jsonFactory = new JacksonFactory();    

        Set<String> scopes = new HashSet<String>();
        scopes.add("https://www.google.com/m8/feeds");

        GoogleCredential credential = new GoogleCredential.Builder()
                .setTransport(httpTransport)
                .setJsonFactory(JSON_FACTORY)
                .setServiceAccountId("myserviceuser@xxxxxx.iam.account.com")
                .setServiceAccountPrivateKeyFromP12File(new File("somep12key.p12"))
                .setServiceAccountScopes(scopes)
                .setServiceAccountUser("my_user_name@gmail.com")
                .build();

       credential.refreshToken();
       ContactsService service = new ContactsService("MYAPP");
        service.getRequestFactory().setHeader("User-Agent", "MYAPP");
        service.setHeader("GData-Version", "3.0");
        service.setOAuth2Credentials(credential);

        URL feedUrl = new URL("https://www.google.com/m8/feeds/contacts/default/full");
        ContactFeed resultFeed = service.getFeed(feedUrl, ContactFeed.class);

I also searched heavily through stackoverflow (can't list all references and checked the responses and solutions). But one question was never clearly answered - nor in googles documentaiont nor on all the stackoverflow posts:

• Is it realy possible to impersonate a serviceaccount with a normal user@gmail.com user (I mean a normal gmail account with no access to the mentioned admin console in the chapter "Delegating domain-wide authority to the service account" and withouth having a own domain )?

Some say yes, some say no. So what's the absolute truth?

As far as I understand when reading the google docs: The service account can only impersonate on users when you in charge of a own domain and you need to have a google work account with your own domain registered. Then you're able to access the admin console and can grant access to the service account.

Thanks for your patience and for your time to answer.

Best regards Matt

Answer 1

The short answer is no, it's not possible to perform service-account impersonate of a @gmail.com account. The key reason is that although the service account OAuth flow doesn't involve an authorization screen, at the end of the day someone must still say "I authorize this application to impersonate this user."

In the case of a Google Apps domain that person is the domain administrator, who has the authority to approve apps for all users in the domain. For an @gmail.com account, there is no other authority that can approve this on your behalf. And if you have to ask the user for authorization anyway, they it just makes sense to use the regular 3-legged OAuth flow to prompt the user for authorization, get a refresh token, etc.

Now for a while there was a trick where you could take an @gmail.com user through the regular 3-legged flow, and once they approved it use the service account flow from then on. This lead to some strange problems however, so we've disabled that option. This may be why there was disagreement in the past about if this is possible.