Failed to request access token for Fusion Tables API with Google Service Account - google-fusion-tables

Question

I have been successfully using Google API (via HTTP/REST, as well as using the .NET client library) with a Google Service Account to access the files in Google Drive.
Recently, I am exploring the Fusion Tables. I am able to use the API with user authorization via a web application. However, when I try to access it using Google Service Account under the same project, it failed with the below error, whenever I have https://www.googleapis.com/auth/fusiontables in the scope:
https:// www.googleapis.com/oauth2/v3/token
HTTP 401
{"error": "unauthorized_client", "error_description": "Unauthorized client or scope in request." }
The error goes away, when I remove https:// www.googleapis.com/auth/fusiontables and the same code block works fine with https://www.googleapis.com/auth/drive and other scopes.
I have checked and confirmed the "Fusion Tables API" is already enabled for my project at Google Developers Console. (Otherwise, my user authorization via a web application would not be working at the first place.)
Is there anything which I could have missed out? Any help would be greatly appreciated.

Answer 1

I just come across this:
Google drive service account and "Unauthorized client or scope in request"
Even though it does not seems to be related at the first glance, it is indeed the same issue.
Problem resolved after removing User = svcAcct, from the below code block.
ServiceAccountCredential credential;
credential = new ServiceAccountCredential(
new ServiceAccountCredential.Initializer(svcAcct) {
// User = svcAcct, *** removed ***
Scopes = new System.Collections.Generic.List<string>(scopes.Split(' '))
}.FromCertificate(certificate)
);
Hence, here is the general advise:
DO NOT call ServiceAccountCredential.Initializer with User = svcAcct unnecessarily.
Only do this when you are trying to impersonating a difference user
(with the condition that the appropriate setup has been correctly done
in Google Apps Admin Console).
Even though it may not produce any error under certain cases, there
are some unexpected behaviors when including an email address of the
service account itself in the JWT claim set as the value of the "sub"
field.