What is your goal?
Find a secure way for implementing continuous OAuth flow connection - cannot save credentials safely (app does not support redirect, need to get token first, then pass the token).
What is the problem & what have you tried?
The App I need to connect to via HTTP request does not support “Authorization Code / Implicit flow” in the Oauth. It works on Continuous flow.
I need to use a POST request with Client ID and Client Secret to get a token, which is valid for 5mins. And then pass this token in the subsequent calls.
This method does not use redirect, so I cannot use the Oauth 2.0 verifier and save it safely in the connections.
This means that I have to send the Client ID and Client Secret openly, without masking.
I have to store this somewhere, so currently I am using Data store and “security through obscurity”, because nobody on the team is at the level to use it.
I am planning on making the token generating scenario on demand, and turning off logging, so it will not have the ID and Secret disclosed in the logs.
However, I see this as a super big security risk.
What other ways of securely storing this do I have? Why cannot I store just a Client ID and Client Secret as a key?
Does Make have any other way to protect this information, saving some environment variables?
Any ideas or suggestions please, how do you guys solve this?
And as a subsequent question, I do have an endpoint to refresh the token if needed, however, I would expect Make connector to handle the refresh instead of having to work with it.
Does anyone have any similarly behaving app?
How do you go about it?
My scenarios will be rather short with this, still, I would prefer not having to refresh the token..
Hello @Alena_Rebernik
Welcome to the Community! I really appreciate that you’re taking security seriously- most “automation gurus” from YouTube would happily pass unmasked tokens straight into the HTTP module
You have a few different approaches here.
First- create a separate scenario responsible only for authorization and store the encrypted token in Make’s database.
Second- create your own app. Unfortunately, this requires deeper knowledge of the platform and some actual programming knowledge as you must work with the code.
Let’s focus on the first approach.
You can use a database where you store both the token and its expiration timestamp.
In your main workflow, you check the database first:
- if the token is still valid → encode it and use it in the scenario,
- if the token has expired → trigger a second scenario via webhook, refresh the token there, store the new value in the database, and return it in the webhook response.
This way your main flow always works with a valid token and never has to deal with the refresh logic directly. Also, you won’t waste operations on constant token refresh- most likely during nighttime you don’t need to have a valid token waiting for you.
The key building block you should use here is:
https://www.make.com/en/integrations/crypto
I created simplified diagram to show you general process:
Let’s briefly touch on the second approach as well.
You can also build your own app within Make.
Building your own app gives you full control over authentication and token lifecycle without need to use data store, but it comes with a much higher entry barrier and requires some work with the code. Make provides very solid documentation for this path here:
Have a nice day,
Michal
2 Likes
@mszymkowiak Hello and thank you!
I knew there must be something. I will try to incorporate the encryption. 
Ok, storing the token and the timestamp sounds like a great idea to try.
However, I only need to check if the token is valid for the scenario that is using it in its current run. Otherwise it would keep refreshing the token indefinitely. I am am thinking of what to do with it, maybe using a similar mechanism in “scenario still running" variable.. if yes, and invalidation period is coming soon, then refresh, if not, then don’t refresh. And then remove all the finished runs from the data store..
More ideas? 
The scenario responsible for obtaining the token is triggered by the main scenario- it does not run every 5 minutes to keep the token valid. That would be pointless.
So each run gives you a 5-minute window- if you have the next run of your main scenario- it uses the same token. If the next run is after 5 minutes - it triggers for a new token.
