Hello Community,
I try to use the HTTP module with oauth2 authentication. I want to use grant type Client Credentials but i can only choose ‘Authorization Code’ or ‘Implicit’ for the oauth2 connection. How can i get the other methode into the HTTP.
Regards,
Arjan
Hey @Arjan_Ribberink I don’t think this is currently available in the HTTP module.
You can however create an easy App within Make and develop this grant type flow, then create an easy “Make an API call” module so you can do any type of call you want.
Have you tried the basic authentication http module? It uses client credentials.
It wont work because it’s a kind of aouth en works dirictly with a token you recieve after the first call with the clientid and the secret
But have you tried it first? Some apis still support basic auth even through they specify oauth2 only in the docs.
Just tried it again. No succes
{"name":"UnauthorizedError","message":"Format is Authorization: Bearer [token]"}
Need the oauth2 methode
That’s too bad. Sorry about that.
Thanks for your thought!
Did anyone have any luck with this?
I got the same problem.
In these situations I will edit the headers manually. Like just set the header with key of Authorization to the value of Bearer MYSECRETCLIENTKEY.
This is really too bad. I am trying to create an HTTP “Make a request” call to manually create the token at the start of a scenario:
I am sending a POST to the oAuth token URL with the raw body set to
grant_type=client_credentials
&client_id=xxx
&client_secret=xxx
&scope=all
but I am getting an invalid_client 401 error coming back. Any ideas why? I have confirmed the client ID and client Secret and they work in Postman perfectly.
This sort of “hack” will work but what about when the token expires? Your scenario will stop working and you’ll need to set the token fresh again manually.
By the way there are 7 oAuth grant types supported and Make only supports implicit and authorization code right now in the HTTP app.
I’d try sending that same payload to webhook.site instead of the target API to see what actually gets sent. Just replace the URL with your custom webhook.site URL (they make one for every user). I find that kind of introspection can help a lot in diagnosing.
Depends on the details of your API! If your API uses client credentials to get an access token, then yes, you need to make that call first before you call the useful API endpoint with the access token you just redeemed in the previous step.
This server-server flow (e.g. client credentials or refresh token) is tricky but possible - it’s all just sequenced post requests. The implicit/authorization code flow is the one that requires user intervention - I suspect that’s why there are special selectors for it.
Hi @Ray_Deck thats a great idea. Does this offer you some more infos than the Integromat (Make) DevTool ? That’s how I look into what I am actually sending to the API 
Hi @alex.newpath, I am not sure if that’s exactly the same because it wasn’t oAuth2, so please just ignore it if I understood it completely wrong 
When I authenticate to some programs using client credentials, it’s quite common that the token/cookies expire. I feel like everyone handles refreshing a little different but in one example it’s a POST request to the “/me” endpoint containing the token of the first Authentication-request. I try to understand how they refresh it by looking at the developer console for a certain amount of time
Once I understand, I create a small custom app.
0. Setting up the connection → receiving a (semi-) permanent refresh-token
Basically chaining two requests:
As I said, I am not really sure if that’s the challenge here. But this way I don’t need to manually refresh any tokens
Well I figured out how to get a token with the HTTP module. The body I was sending needs to be JSON for the POST to the Token URL.
To test this I used the new Scenario inputs and designed these inputs:
Then in the HTTP module it is configured as follows. The tokenURL will be the full URL of the oAuth token URL you are using to obtain the token.
Note the scenario input variables:
And this is the key part, the Request content body:
Note that it is valid JSON, and all the variables are enclosed in double quotes. If you leave off the double quotes, it is not valid JSON and your token will fail.
The result is a response body with the token you can use in subsequent HTTP calls to API endpoints:
The header looks like this:
Authorization: Bearer <token>
where Authorization is the key and Bearer <token> is the value
Thanks for your response. I can see how this could refresh the token, but I was having problems even GETTING the token.
@alex.newpath can you explain the whole workflow?
I need to allow users to authenticate with, say, Google Sheets by clicking on a button on my app and then use those credentials to call a webhook/API that will trigger a flow in Make.
Is something like that that you were able to figure out?
