We’re getting a response of "HTTP Basic: Access denied." when we try to exchange the code for tokens. We have tried in code and in Postman and get the same issue. Here’s what we are doing:
1. Hitting the https://api.sandbox.freeagent.com/v2/approve_app endpoint with our client_id and redirect url.
2. This is successful and our redirect url is hit with the code. So far so good…
3. We are then sending a post with basic auth (client_id and client_secret) with the code, grant_type and redirect_url params all set
4. This is where we are getting the Access denied response…
I have gone through all the docs and tried a bunch of stuff but can’t get the token response… I feel like I’m probably missing something simple but can’t find it!!
Thanks for your help!
Here are 2 screenshots from Postman, had to join them as I can only upload one image…
Hi Burrotech,
Sorry for the delay in response to you - our automated systems initially flagged your post as spam, and during the process to mark it as legitimate, it got lost. And also, sorry that you’re having difficulty getting set up!
From the screenshot you’ve sent it looks like the problem is with the format of the code parameter. The Postman screenshot shows code: code=auth_token_in_hexadecimal. But that means that code is written twice as a parameter. Much like with the grant_type it should just be authorization_code, code should just beauth_token_in_hexadecimal.
In this case: code: 18qE1zv-…..
I hope that helps! Let us know if it doesn’t, and we’ll be happy to get back to you.
James
Hi James
Thanks for looking at this; The postman stuff was mostly copy and pasted from our code to demonstrate the issue - I changed it as suggested and it still gives us the Access denied. Here is a cURL version of the issue (exported from postman):
curl --location 'https://api.sandbox.freeagent.com/v2/token_endpoint' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic SktQN2dhVzE0V0xuSGh4UUFCYlFhUTotTXZjdkxxQTdNQ29zODNDa1BydVRn' \
--data '{
"grant_type": "authorization_code",
"code": "1c1kFZx5-xWBgahV5uRQ-Ii5x8hA6jy6vt-5OSbL_",
"redirect_url": "http://localhost:3000/api/freeagent"
}'
Hi again!
Just to let you know we have been looking at this and have yet to be able to replicate it exactly (though I can see the request in our logs). We’re continuing to investigate and will get back to you as soon as we have something.
Unless someone else reading has an idea?
James
Try redirect_uri instead of redirect_url.
Hi Andrew, thanks for spotting that, unfortunately it didn’t make any difference and we still get a 401. The fact that the error message mentions HTTP Basic leads me to think that it is not recognising the basic auth creds so I am going to create a new app in FreeAgent and try some other creds.
How about if you remove the content-type header?
Removing it gives a 400 bad request response. I tried various other encoding methods as well but they all give the same 401 error as above.
I finally got to the bottom of it - the documentation at FreeAgent Developer Dashboard states that the client_id and client_secret should be passed as basic auth params but I found that they actually need to be sent as part of the post data instead. So for the token exchange it is a regular post with code, client_id, and client_secret all passed in the json data (along with grant_type and redirect_uri). This is more consistent with the standard OAUTH 2 protocol than using the basic auth method which is why I thought it was worth a try.
I’m surprised that no-one else has had this issue as it is part of the fundamental API exchange!
Here is the postman query showing how the client_id and client_secret are included in the post data.
Great news that you now have authorization working, and sorry that it’s taken so long. Thanks for identifying what steered you wrong as well. We’ll have a look at that and update it accordingly.
We have been thinking about how we can support the OAuth journey more smoothly for people too, since it’s a source of friction. Currently we’re thinking about giving a list of examples of languages/frameworks going through the authorization process.
We’ll announce any change like that on the forum.
If you need other API support, don’t hesitate to ask in another thread!
James
Thanks James
What would have been really useful for me would have been some cURL commands similar to one that I posted in this thread - I think most devs would be able to understand that and they could simply tweak the params and run the command in terminal. This would also save you trying to work out the various languages and frameworks that need to be catered for.
Paul
1 Like
Hmm, how weird that it didn’t work when you passed the client_id and client_secret in an authorization header (Authorization: Basic ...). I’ve been doing that for years, via Ruby rather than curl, without any trouble.
Anyway, good news that you got it working!
1 Like
