Why is time-based trigger authorization expiring every week?

user_7480881 0
Viewed 299

tl;dr: I'm running a script via a time-based trigger, but Apps Script is throwing the "Authorization is required to perform that action." error every week. I suspect it's because of new OAuth "test user" requirements but am not sure.

I'm currently invoking a Google Apps Script via a time-based trigger. A while back I created a Google Cloud Platform (GCP) project for this script as well as a few others it works in conjunction with.

Because I'm running in the context of a personal Google account, the GCP project is not part of an organization. This teams that the required OAuth consent screen is set to "external", in which GCP states "Your app will start in testing mode and will only be available to users you add to the list of test users." My account is listed as a test user.

I'm observing that my time-based trigger fails with the "Authorization is required to perform that action." error every week. This is a dealbreaker for this script, which must run on its own for long periods of time.

I haven't seen this behavior in the past and am guessing that these OAuth settings requiring test users are new and are not affecting my older GCP projects (which run find).

Any ideas would be greatly appreciated.

google-apps-script
2 Answers

Try to make a new Apps Script project that isn't linked to a user controlled GCP project

That is, do not link your Apps Script project to a GCP project. Let it use the default (Google controlled) project for general Apps Script projects. Cloud Platform Projects

More information about deauthorization.

It seems that a recent security restriction has come into force. This issue was raised with Google here:

Random Deauthorizations for script since Editor Update with no changes to code

In which these issues are discussed. Though as you will have seen:

Authorizations by a test user will expire seven days from the time of consent.

Source

A Google Cloud Platform project with an OAuth consent screen configured for an external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days.

Source

Since you have a GMail account and not a Workspace account, you won't be able to set the GCP status as "internal", and so, without verifying your project, you won't be able to have authorizations last longer than 7 days for this use case.

In the issue tracker thread, linked above, the OP says:

I have since removed the projects from a standard GCP and changed to a default Apps Script managed project (for the ones that I could and don't need as verbose logging) and they have stopped having authentication issues.

This is presumably because the Apps Script projects have some more leeway for these kind of personal applications. I am running a few scripts on my GMail account on time-based triggers (with derfault GCP project) and it works without a hitch

If you absolutely need it to be in a GCP project, then you'd have to pay for a Workspace account and set the project to "Internal".

References

user_104450170
user_11925570
Related