I have an issue with the impersonation on my domain with team drives.
Indeed, when I run: rclone -vv --drive-impersonate usr@domain.com lsf GDrive:, I get the following error:
Response: {
"error": "unauthorized_client",
"error_description": "Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."
}
Where client_id matches the one in the service_account_file file. (I also tried without specifying the client_id in .rclone.conf, did not change anything).
I made sure the service account has proper domain-wide delegation enabled
The client_id has been granted https://www.googleapis.com/auth/drive rights.
No, there's no client_secret in the .rclone.conf nor the sa-auth.json.
But the latter has been generated by Google so I guess it can be assumed correct.
But what is the point of using a service account login if I have to create my own app and do the OAuth procedure?
I am not sure this is actually the solution since in the sa-auth.json I have the private_key, client_id, auth_uri, token_uri...
Secondly, as I said in the original post, I also tried without specifying the client_id in .rclone.conf, it did not change anything.
Lordy lord! Nick is asking me for help? (let me get a photo of this )
To be clear, I haven't set up a SA for domain-wide-delegation because I don't own a domain, but let's see if I can add anything here...
Well, let's get the basics out of the way:
Is the user you are trying to impersonate a member of the domain? This error will occur if you tried to for example impersonate an @gmail.com user or one in another domain than your own. Logically "domain-wide-delegation" permissions can't extend outside of that domain.
Select “Show more” and then “Advanced settings”
Select “Manage API client access” in the “Authentication” section
In the “Client Name” field enter the service account’s “Client ID” - this can be found in the Developer Console under “IAM & Admin” -> “Service Accounts”, then “View Client ID” for the newly created service account. It is a ~21 character numerical string.
Lastly - is it important for you to actually impersonate users for administrative purposes - or is all you really care about allowing the SA to access the files? If it is the latter we can use an alternate method for that if we do not figure out the initial problem.
To be clear: If you have a service account in the config and the TD is shared with that service account (directly with SA email or SA email in a group) then you do not have to auth with client_id / secret.
Correct - that is the alternative method I mentioned.
But this does not really replace the impersonation feature as that has many administrative and organizational uses. It is just an alternative way to access files with an SA - which is often all that people were really looking to do in the first place.
I had the same problem and found one probable issue:
You have to create the Credentials after you enable the “Enable G Suite Domain-wide Delegation” checkbox.
If you do like me and follow the wizard, download your json credentials and then enable this, the credentials won't work.
You have to create new credentials and they will work!