Oauth2 authentication constantly needing re-authorization

Hello - for some reason it seems Oauth2 authentication is not working properly? I’m using Google Oauth2 authentication and I can see from server logs that the auth_token is not always being sent properly. If I re-authenticate my API, everything works again, but this has happened a number of times today and in general doesn’t happen as I think you are typically using the refresh token to keep users in session?

Thanks!

Hey @gilcrest!

Does it prompt you to reauthenticate every time an app using the API is opened, or does it work for a while and then stop?

  • If the first, the login test URL might not be a valid endpoint. When the apps are opened, they will make a test request to that endpoint. If a non-200 code is returned, it will prompt the user to authenticate
  • If the second, I’m curious if we might not be receiving or saving the refresh token correctly for the setup for some reason.

In either case, would you mind sharing a (redacted) screenshot of the resource setup page here?

Hey @alex-w - it’s the latter. However, regarding your first point - it seems you made a change a little while back where I can no longer specify the Test Request endpoint. It always defaults to the Base URL endpoint and is no longer configurable. This runs counter to most of your docs, actually… Let me get you screenshot, give me a minute…

Thanks for your help!

Sorry for the multiple pics - small laptop…




The test URL will need to be an endpoint off of the base url- you should be able to configure that in the input to the right of the base url in the Login test URL setting in that last screenshot here. Any endpoint would work- as long as it returns a 200 success code if you are already authenticated

1 Like

This setup looks essentially the same as my own Google Calendar API setup (which should be very similar), though I’ve got https://www.googleapis.com/oauth2/v4/token as the Access Token URL

1 Like

Thanks @alex-w - I’m going to deploy a simple ping service off the base url endpoint that returns either a 200 if you pass a valid access_token, a 401 “Unauthorized” for missing or bad authentication and a 403 “Forbidden” when the user is authenticated but isn’t authorized to perform the requested operation on the given resource. I’ll also switch to the v4 access token URL…

Thanks again - will let you know how it goes.

Apologies here @gilcrest! After digging into the issue we found a bug in how we were processing the refresh token in this case. This should be fixed now, and is likely the cause of the original issue you were seeing here.

Without the test URL set up if a resource’s authenticated expires I don’t believe there is any prompt or notification for the users- the queries will just start being unauthorized. So at the very least, having the setup to notify users and prompt them to re-authenticate the resource is still worthwhile.

1 Like

100% agree that the effort is worthwhile and should have it up and running within the hour. I’m glad you found the bug as well though as we hadn’t experienced this issue at all before and it was confusing.

I’d like to call out that in your core docs for Oauth2 login setup, the Login Test URL in the screenshot is confusing as that is definitely not going to be someone’s base URL, so I was always confused as to what you were looking for here and left it blank. Now I understand that it’s critical!

Even in the immediately following section about the consent screen, there is only a Base URL present. To be fair, this base URL may be setup properly to send the appropriate http response codes, but I think it could just be a little clearer between these two sections. Sorry to complain - your docs are generally really great!

Thanks again!!!

Sorry to complain - your docs are generally really great!

It’s fine haha, we have a lot of work to do on our documentation still. In this case, the UI is outdated in the screenshots are we need to go through and update this section (the product has been improving too quickly!)

I appreciate your feedback!

One other question @alex-w - the behavior of the Test URL is different that the API Resource in terms of display. If I have a Base URL that looks like in https://www.example.com/api/v1/search, in the app API Resource editor, your team is appending a “/” at the end of the url, e.g. https://www.example.com/api/v1/search/ and it’s clear that I do not need to prepend the / before the route. So, if I am setting up a Query to hit my ping route in the app, all I would need to do is add ping to the input box.

For the Test URL, the trailing “/” is not appended to the Base URL, so I’m not sure if I should be inputting /ping or ping

In either case, when I’m using the button below, I am able to authenticate, but there’s no success message or anything like that to tell me if it truly worked. I’m also not seeing calls to my backend logs for this endpoint. Sorry, just not sure what I’m missing here!

Screen Shot 2020-07-30 at 4.27.18 PM

Thanks again!

Dan

ok, nevermind - I see it in the logs now! It looks like you do not need to prepend the “/” character. It would be helpful, I think, if in the Test URL dialogue box, you added the trailing “/” character, so it was clear and consistent with the behavior in the Query editor…

Thanks again!

1 Like

Last thing, I promise - just an FYI - I left the Access Token URL https://oauth2.googleapis.com/token and it works great. I believe this URL is the canonical access token URL for Google now (vs. the versioned one you are using), given their latest docs: https://developers.google.com/identity/protocols/oauth2/web-server#httprest

Thanks!