OAuth2 Token Not Being Stored?

Hey all! I'm having a little trouble getting connected to Basecamp's API using OAuth2.

I've got my app registered with Basecamp, which has given me a client id and secret. Here's a screenshot of my resource setup:

When I click the test button at the bottom, I'm taken to the following screens:

I click Authorize on retool, it takes me to basecamp. I click allow access and then it takes me to the retool callback url with this error. If I look at the url, I can see the access_token and refresh_token in the url but I'm guessing something isn't right with how I've setup the resource because the tokens are not being saved on Retools side.

When I click "see token status" there are none.

And if I try a request, the headers are sending "OAUTH2_TOKEN" instead of the actual token.

Any ideas on where I've gone wrong?

Thanks!
-Tyler

Hey @thetylerherron!

Would you mind checking the networking tab or console of your browser's developer tools while you run through the OAuth flow? Nothing's jumping out at me from those screenshots :thinking: hopefully we can find a more verbose error message there.

Hey Kabirdas, the console isn't much help but there might be a couple of things in there that are interesting.

First of all, the actual console doesn't give anything else in relation to the 400 error. It's also blank.

This error does pop up on all three pages. Not sure what this is:

Screenshot 2022-12-05 172231

These are from the last screen with the error from the retool page, in the network tab of the dev tools:

Screenshot 2022-12-05 172338
Screenshot 2022-12-05 172320

I'm stumped as well.

Alright! Got something you can try which seems to do it on my end:

Can you see if setting ?type=web_server on both the Authorization and Access Token URLs works?

You'll also want to move the Authorization from your URL parameters to your headers.

Hey that did it! Thanks!!

I had tried using user_agent in both, and that didn't work. Should have thought to try web_server.

Appreciate the help!

Awesome! :grin:

Hi, I'm running into the same initial problem as OP. Can you explain more about what you mean by "setting ?type=web_server on both the Authorization and Access Token URLs" (I'm not a developer)? Same question for moving "Authorization from URL parameters to headers". It looks like if I can validate my token status then the API I've configured should work.

Hey @maximus4133! Thank you for coming to office hours this week :slight_smile:

Let us know if the current solution stops working for you and we'll work together to try setting up this different auth method:

https://dev.fitbit.com/build/reference/web-api/developer-guide/authorization/#Other-Supported-Authorization-Flows

:crossed_fingers:

@maximus4133 actually...could you try enabling this feature flag (Settings > Beta)?

And then in your resource, you can try to switch your header section back to

Bearer OAUTH2_TOKEN

This might do the trick! Let me know if you're able to give this a try :slight_smile:

Hi Victoria, thank you so much for your time during yesterday's office hours session!

No luck unfortunately with the proposed solution. I enabled the beta feature, switched the header back to Bearer OAUTH2_TOKEN, and I still end up the same message in my app:

FWIW, I know that at some point in the past I was able to validate the token status of my resource - this was several months ago and I can't recall what I had done to allow this happen. I will tried to backtrack and figure out what I had put in place in order for the access token to be recognized by Retool.

Also, the hard-coded token from Postman unfortunately does change after it expires and needs to be refreshed, so it looks like even that will only be a temporary solution; I'll need to jump back into Postman to refresh/retrieve a new token and replace it in my Resource each time it expires.

Thank you very much though for looking into this a bit more. I'm excited to at least have a temporary workaround in place. Please let me know if you and the team happen to come up with any additional solutions.

Darn! We thought that flag would be the answer for sure. I wonder if the flag is getting overwritten by the value in your header field. If you don’t mind, could you try removing the authorization header entirely and leaving the flag on?

In the meantime, I’ll speak with the engineering team again to see if there’s anything else we can try :smiling_face_with_tear: