Dec 13, 2022 01:05 PM
I'm not certain if the OAuth flow is working as expected...
When initiating an OAuth flow for an existing, and currently logged-in user, the OAuth pattern works as expected. After the OAuth consent screen is displayed, flow correctly redirects the user to the redirect_uri.
However, if a user is NOT logged in, the flow works to the point of providing an Airtable login screen for the user and then drops them into their admin page WITHOUT a OAuth consent screen. I would have presumed that for users who have not logged in, Airtable would allow them to login and then proceed to the OAuth consent process. As it stands now, users are dropped into Airtable without ever redirecting back to the calling site leaving users stranded.
And assistance on this would be appreciated.
Solved! Go to Solution.
Jan 27, 2023 02:24 PM
Hi @Ian_Erickson - Thanks for your patience! The team has been able to track down the issue - there is a bug in our redirect after login flow that interacts with how the URL parameters in the authorization URL are defined.
We’ll be looking into fixing this on our end, but for now, you could get around this on your end by making sure to URL-encode the redirect_uri and scope parameters when constructing your authorization URL.
We’ll add a note to our documentation about this as well.
Dec 19, 2022 08:26 AM
Hi @Ian_Erickson ,
Thank you for the bug report! I'm an engineer on the API team at Airtable, this is unexpected behaviour that we are now looking in to. I will keep you updated on our investigation, though as it is now the holiday period, it will take us some extra time to address.
As you mentioned, the workaround for now would be to ask users to log in to Airtable before starting the flow.
Thank you again for the report,
Emma
Jan 27, 2023 02:24 PM
Hi @Ian_Erickson - Thanks for your patience! The team has been able to track down the issue - there is a bug in our redirect after login flow that interacts with how the URL parameters in the authorization URL are defined.
We’ll be looking into fixing this on our end, but for now, you could get around this on your end by making sure to URL-encode the redirect_uri and scope parameters when constructing your authorization URL.
We’ll add a note to our documentation about this as well.
Feb 01, 2023 11:33 AM
I have confirmed that this works as expected. Many thanks!
Feb 14, 2023 03:42 PM
Great, glad to hear that @Ian_Erickson ! Wanted to let you know that we have fixed this issue and you no longer need to URL-encode parameters as a workaround.
Feb 15, 2024 03:48 AM - edited Feb 15, 2024 06:48 AM
We are getting "Error: invalid_client, Description: Invalid client credentials." while connecting OAuth using Postman or webapp.
Thank you in advance for your time and assistance. We look forward to any feedback or suggestions you may have.