Google Drive OAuth for Scale

How To
,
1

Hey everyone,

I’m following up on a previous post I made here: [Link to previous post]. In that post, I shared how we successfully configured a Make.com scenario to upload multiple files from an HTTP payload to Google Drive. We used an Array Iterator and MIME-type filtering to download files and store them in the correct folders. That worked well for our use case, but now we’re facing a scalability challenge.

Project Overview Recap: Our automation uses Make.com to handle files uploaded through a custom form in Go High Level (GHL), then saves them to a designated Google Drive folder. Since we’re aiming to scale this to multiple client accounts (clients who don’t have access to Make.com), we realized we need a system to manage Google OAuth tokens securely and ensure the automation functions seamlessly for each client’s subaccount.

Current Setup:

  • We created a Data Storage module in Make.com to store Google Auth tokens and refresh tokens for each client.
  • The goal is to match these stored tokens dynamically with each client’s GHL account, allowing the automation to run for each client without them having a Make.com account or needing manual intervention.

The Challenge: I need help figuring out how to correctly and securely match and utilize these Google Auth tokens for multiple client subaccounts. Specifically:

  1. How can I get different clients authorized and store the tokens stored in Make.com Data Storage?
  2. What is the best way to handle token refresh operations?
  3. How do I ensure this all ties to the correct client subaccount in GHL and that no further action is required from them after the authorize?

Any advice, recommendations, or best practices on how to make this setup scalable would be greatly appreciated!

Thanks in advance for your help!

1 Like
2

You’ll need to use scenario (A) one to show the “OAuth Login” page to the user.

You’ll need another scenario (B) to handle the “callback” from Google, using a Custom Webhook module.

Then you can store it in the data store.

You’ll need a scheduled scenario (C) to run through all client tokens to get a refresh token before it expires.

The callback from (B) should contain the user’s email address or ID. Store that in the data store along with the tokens.

Hope this helps! Let me know if there are any further questions or issues.

— @samliew

P.S.: Investing some effort into the Make Academy will save you lots of time and frustration using Make.

2 Likes
3

Would you be willing to go into further detail or provide a resource that could help? The help section does not cover this very well and I am not finding the answers I need on YouTube either.

4

Did you know, this forum has a Hire a Pro category, where you can post your request for off-site specialised help on other platforms (video call/screenshare/private messaging/etc.)? This may help you get your issue resolved faster especially if it is urgent. It is important to post your request in the Hire a Pro category, as forum members are not allowed to advertise their services (even offer FREE assistance to help) in other categories like here. Once you have posted in the Hire a Pro category, that will allow other members like me to provide booking links to our calendars for a free consultation and video assistance (including screenshare)!

5

Thanks, I am aware of the category. For my situation and budget I would prefer to learn for myself over hiring someone to do things for me. I wouldn’t feel right asking for free help in the Hire a Pro category.

Also, I truly like to help others. So, once I finishing banging my head into the wall I will detail the conclusion here for everyone to freely use in the future when they use the forums search function, just like I did with my last post.

1 Like
6

Hello @Jonathan_Killam,

what you are trying to achieve is very specific, and that explains why you won’t find any relevant asset in the Make Help Center or Youtube.

@samliew gave you excellent ideas about how to handle these customer access tokens. What I can try to do is to give you more details about what he said, hoping it will guide you.

First of all, you won’t be able to use the default Google Drive Make App, because it doesn’t allow to store access tokens that were not generated in Make. And you won’t be able to select the relevant connection dynamically, unless you use the Enterprise version of Make that provides “Dynamic Connections”, but in that case as well, you will need your customers to access Make and create their own connection.
It means that you have to use the the HTTP Make a request module, and send the Authorization Bearer token in the headers.

You also will have to ask your customers to go to their Google Workspace and generate a new client application, with a new ClientID/Secret and a specific redirect url (see below). Your customer will then have to give you his clientid/secret.

@samliew said that you need a scenario A for login and scenario B for redirect: In fact, you may not need Scenario A, but you still need your clients to grant access to Make (this type of Oauth flow requires the user anyway), so you have to provide them with a Login page where there will be redirected to Google to log in and to grant access to their workspace.
And the user’s browser should redirect to Scenario B, because it’s the one that will request the access token from the Authorization Code. This is the redirect url you have to provide your clients so that they add it when they configure their Consuming App in their Google Workspace.
To summarize this part, you need to build a new webhook scenario, and give its URL to your clients so that they add it in the “redirect url” section of the client app configuration in Google Workspace.

Then, in your main scenario, you need to select the relevant access token, and @samliew suggested that you use the client’s email address. It could be a unique ID you get from GHL.
What you need is to figure out a way to get a relevant information during the Token generation process that you can also use when GHL calls your main scenario.
I’m not super familiar with Google Oauth, but maybe you can you the “state” parameter to pass the customer info (email, unique id, etc)/ See here Using OAuth 2.0 for Web Server Applications  |  Authorization  |  Google for Developers
You will then store the access_token, refreh_token, client unique id, expiration datetime, the client id and secrect used to authenticate (you will need them to refresh the tokens).

In your main scenario, assuming GHL provides you with your client information, you will be able to pick the relevant access_token for Google.
For the refresh of the token, as @samliew said, you need another scenario to regularly check the expiration dates in the Data Store, and refresh those that will expire.

It’s a lot of things to do, that’s why @samliew suggested you get some help from the Make partners community.

I hope you’ll manage from the instructions @samliew and myself gave you.

Kind regards

Benjamin

4 Likes
7

Thank you so much for your response Benjamin!
I actually just finished up last night with this project. I have a few small things to button up and then I will be detailing how I accomplished my goal. I hope to have the post for the community within the next few days.
Have a blessed day!
-Jonathan Killam

1 Like
8

@Jonathan_Killam super happy to read that you managed to do it. Yes, if you could share the steps you went through, it will be an extremely valuable asset!!

Have a lovely day, and see you soon!

Cheers,

Benjamin