0
votes

I need to use G Suite account to insert a calendar include a hangout meet but I can't even insert the event, I always get the 403 response

403 Forbidden
{
  "code" : 403,
  "errors" : [ {
    "domain" : "calendar",
    "message" : "Service accounts cannot invite attendees without Domain-Wide Delegation of Authority.",
    "reason" : "forbiddenForServiceAccounts"
  } ],
  "message" : "Service accounts cannot invite attendees without Domain-Wide Delegation of Authority."
}

I use the GCP p12 file and the service account to do the calendar.

I also click the Enable G Suite domain-wide delegation box and add my clientId and scope of

https://www.googleapis.com/auth/admin.directory.resource.calendar, https://www.googleapis.com/auth/calendar.events

at G Suite Admin console

What may be the problem!?

By the way, do I need to set the OAuth consent screen!? I already save it, but not been approve by google.

Can anyone help pls!!

In the begining I get credentials by the following code

credentials = new GoogleCredential.Builder().setTransport(httpTransport).setJsonFactory(JSON_FACTORY)
                    .setServiceAccountId(CalendarEntity.CALENDARID)
                    .setServiceAccountPrivateKeyFromP12File(new File(P12FILEPATH))
                    .setServiceAccountScopes(Collections.singleton(CalendarScopes.CALENDAR)).build();

And then I add (my G Suite account)

.setServiceAccountUser("[email protected]") 

it response 401 Unauthorized How can I slove this!? thx

1

1 Answers

1
votes

You are missing impersonation.

The purpose of granting domain-wide authority to a Service Account is for these accounts to be able to access data on behalf of users in the domain.

If you grant it domain-wide authority but are not "impersonating" any account, the Service Account is acting as if you hadn't granted this authority: it is trying to access its own Calendars, Drive files, etc., or in this case, trying to insert an Event: something which the Service Account cannot currently do, as I guess you already know.

When the Service Account impersonates another user in the domain (that is, when it acts on behalf of the user), the Service Account can access the resources this user can access. Nothing more, nothing less. What makes delegation useful is that it can do this with any user in the domain.

To impersonate another user, you have to specify this user's email address. I don't know which library you are using, if any, but here you can see how to impersonate another user with Python, Java, and plain HTTP/REST. Refer to this answer if you need to do it in the Node.js library. If you are using another library, look for the corresponding method in the library documentation.

Reference: