Google workspace Add-on with associated server: managing OAuth and permissions

caseyy_2132363 0
Viewed 153

I am working on a project I inherited that adds some functionality to Google Docs through a workspace add-on written in Google Script. The add-on makes API requests to a standalone web application. The web app is required to have access to some of the users' Google data (e.g. Gmail), sometimes while the user is offline.

The way that I'm giving my server access to Google data is to use apps-script-oauth2 to kick off an authentication workflow using https://accounts.google.com/o/oauth2/auth as the base, and configure it with all of the Google-related scopes that the server will need. (I know this library says it for "non-Google" OAuth, but this was built before I started on the project, and I'm unaware of a better way to do it). Once I get an id_token and a refresh_token, I send it to our server and store the refresh token encrypted in a database.

When testing this works fine, the add-on starts off installed but then asks our server whether the current user exists; if they don't, the user just kicks off the AUTH flow.

When listing in the marketplace, however, the user is asked to confirm all of the scopes they need twice: once when installing the add-on, and then again when creating the service needed to communicate with our server. Even more confounding/alarming is that the second OAuth confirmation screen specifically mentions that certain scopes were already granted to the same app.

My question is basically what is the correct way to deal with this. I realize I can get the OAuth token already granted using the ScriptApp class, but if this doesn't have a refresh token associated with it then giving our server access later is problematic.

google-workspace google-apps-script add-on oauth
1 Answers

I think your flow is correct. You just need to explain the user why you're asking auth for second time. I'm not sure what is your setup, but it might be like this.

  1. Firstly, user install add-on, giving auth to script.

  2. Next, there's something like "Setup Offline" access button, or menu item, or sidebar, which isn't run automatically but maybe on some user interaction.

If your script does nothing without it, you can do like this - if user is new, it doesn't see anything but a simple sheet with "Authorize" button and instructions explaining the user that he has to authorize the SERVER access to his account. It would make sense to user that this isn't the same, so it won't be very strange.

Of course already granted permissions on second screen would look strange, but you can explain that with something like "We need more privileges to be able to manage your account offline. Please approve them on following screen".

In short:

  1. Make a pause between 2 auth screens;
  2. Make second one interactively run by user
  3. Explain why second auth is needed
  4. Remove dialog(button) for auth after it's fine
user_13005180
Related