I am trying to build a scenario that invokes an OAuth 2.0 API.
I created an OAuth 2.0 connection. After filling in my auth URL, token url, client ID and set up the redirect URL in the app and secret I managed to login to the third party app and get back to Make. I can also successfully “Verify” the connection from the Connections view.
However, when I use this connection in a scenario, the scenario fails with the following error:
AccountValidationError
Failed to verify connection ‘My HTTP OAuth 2.0 connection’. “access_denied”
- Failed to verify connection ‘My HTTP OAuth 2.0 connection’. “access_denied”
Origin
Make
I tried changing the request URL to a Make webhook from another workflow but it seems the API request is not even made and already failes upon trying to access/refresh the access token. This is surprising to me as the login and verification from the connections tab seemed to work fine.
Unfortunately I have very limited debugging information to work with. Does anyone with experience with the OAuth 2.0 connector have any idea what could cause the access_denied error despite a working verification on the Connections tab?
Hmm I am starting to think this issue is because my API requires a “Bearer” token prefix in the Authorization header. Is there a way to include it?
Hi @Jan_Willem_Young_Med,
Welcome to the Make Community! The HTTP OAuth2 module will automatically add the Bearer prefix for you. The problem is that Exact Online requires a specific flow for how access tokens are fetched and refreshed. The regular HTTP module cannot handle it; while you can save the connection, the access token is not stored correctly, and you run into this error. (you’ll find that there is no authentication send with your requests at all)
I believe this has to do with the fact that the authorization code is encoded and must be decoded before you can exchange it for a pair of tokens. Make handles this differently. Another quirk is that an access token is valid for 600 seconds, and you can only use a refresh token between 570 and 600 seconds. Not earlier, not later. I have talked to Make about using the HTTP module in combination with Exact Online, and they have told me they would not make changes to the module itself.
So there are few options:
- Use the basic request HTTP module and keep the connection alive manually. You can store the tokens in a datastore and with a second scenario you can refresh them. In the main scenario, you can grab the token from the datastore to use in your requests to Exact Online.
- You can pick one of the community built Exact Online apps. They are built by other make users (but not necessarily Make partners) and afaik are paid. https://www.make.com/en/integrations/exact-online
- If you have interest and/or the technical ability, create your own Exact Online app to handle the authentication precisely as Exact Online expects: Make.com - Custom App Documentation. We have done this, but unfortunately it is not up to standards to be shared.
Cheers,
Henk
1 Like
I see. This also explains why it works sometimes. It always refreshes the token, so it only works in the window where the refresh token is valid 
It appears the existing Exact Online integrations are too limited for our needs, so I think I am going to terminate the OAuth in some API Gateway. But I’ll also explore the possibilities of a Custom App.
Thanks for the quick response!
Exactly! Nothing’s more frustrating than a module that only works sometimes. 
If you’re building a custom app, consider starting with a single, flexible “Make an API Call” module (see the “Universal Module” section in the docs). This approach lets you use any API endpoint and payload you want, while only requiring you to set up authentication once.
Good luck, and I hope you find a solution that fits your needs!
Cheers,
Henk
I ended up intercepting the OAuth token request with a webhook workflow that caches the refresh token. Now the plain HTTP OAuth 2.0 App seems to work reliably.
2 Likes
