tidyverse/googlesheets4

Impact of OAuth out-of-band deprecation

Closed this issue · 2 comments

Google announced that OAuth out-of-band will be deprecated on October 3, 2022 here

I use code that connects to google sheets in a non interactive way by using a service account created on the Google Cloud Platform.

# Authentication:
googlesheets4::gs4_auth(email = 'casper@mypersonalemail.com', path = 'credentials.json')

My_DF <- googlesheets4::read_sheet(master_url, sheet = TabName) 

Connecting this way means that you are not redirected like the image attached:
image

Does this mean all non-compliant requests like using a service account will be blocked?

FYI the issue for tracking the shutdown of OOB auth is here: r-lib/gargle#202. OOB auth should continue to work for the built-in tidyverse client until January 31, 2023, assuming Google continues to honour the extension we were granted.

That being said, I'm confused by what you have above. This code:

googlesheets4::gs4_auth(email = 'casper@mypersonalemail.com', path = 'credentials.json')

is a mash-up of requesting two different forms of auth.

email = 'casper@mypersonalemail.com' is related to an interactive user web flow

path = 'credentials.json' is related to a potentially non interactive service account flow

After successful auth, you should look at gs4_user() to see who you are actually auth'd as: casper@mypersonalemail.com (a normal user) or something more like googlesheets4-dev-testing@robust-fin-276504.iam.gserviceaccount.com (a service account)?

Once you reconcile your intent and what's actually happening, I recommend you simplify the code to provide email or path, but not both.

Once OOB auth is shutdown:

  • Auth as a service account should not be affected.
  • Interactive auth as a user, when running R inside a web browser, WILL be affected.
    It will no longer be possible to obtain fresh tokens this way.
    Affected users will need to use a different method of auth or obtain user tokens elsewhere,
    such as on their local machine, and then deploy that token to the server, where it should still be possible to user (refresh, really) such a token.

This matter is settled now with the changes in gargle 1.3.0.