OAuth 2.0: Incorrect Authorization Flow

[ashtontito]

Reproduction Steps:

1. Generate the https://airtable.com/oauth2/v1/authorize endpoint with the expected query string parameters specified in the authorization reference
2. Open an incognito browser window (In my case I used Google Chrome 64-bit Version 87.0.4280.141 on Windows) and paste the link in step 1.
3. You are taken to a login prompt as expected
   
4. Enter your email, and you are then moved to a "Verify it's you" security prompt, complete the actions
5. You are then taken back to the login prompt where you can enter your password
6. After entering your password, you are then redirected to the home page of the account you logged into
7. In order to continue with the authorization workflow, you have to re-enter the authorization URL generated in Step 1 into the same browser window session, which then takes you to the page to verify/accept scopes and access of your OAuth 2.0 application
8. Then you are redirected back to the specified redirect URI where you can complete the flow required to get an access token.

Expected

In Step 6, you should immediately be sent to the page that asks you to verify/accept scopes of your OAuth 2.0 application, instead of just taking the user to the home page of their Airtable account. The current behaviour causes problems for implementations/consumers of Airtable OAuth 2.0 that expect to be able to complete the authorization flow by only initiating the request in Step 1 once.

[Emma_Yeap]

Hi @ashtontito ,

Thank you for the detailed reproduction steps and screenshots about this issue! I'm an engineer on the API team at Airtable, this is unexpected behaviour that we are now looking in to. I believe it is the same as the issue that @Ian_Erickson posted about here: https://community.airtable.com/t5/development-apis/oauth-flow/td-p/138715 

As mentioned in that thread, the temporary workaround would be to ask users to log in to Airtable before starting the flow. 

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. 

Thank you,

Emma

[ashtontito]

Thanks @Emma_Yeap !

[ashtontito]

Thanks for your help thus far. Could you provide an estimate as to when this might be fixed? The reason I ask is:

• While the workaround may be appropriate for other users, we are authenticating within an embedded browser in our Desktop product. This means a lot of the expected browser functionality is missing, and this workaround would be challenging for our users.
• Our company would like to include this as a part of a release that we have scheduled for late spring. We are blocked on this fix, and are now making contingency plans to launch without including our new Airtable Connector. We have a collection of interested mutual users that this would be servicing, and would love to be able to make this available to them.

Even a rough estimate would be helpful. I just wanted to give you some extra details to see about getting this fix motivated, it truly would be a massive help to us!

[Emma_Yeap]

Hi @ashtontito,

Thanks for the extra info, that context definitely helps us understand how this issue impacts your use case. Excited to hear about your new Airtable Connector too! 

We haven't been able to start work on this item yet. I'm not able to give a definite timeline on when it will be fixed but it is on our backlog for the next month - will keep you updated as we make progress. 

Thanks,

Emma

[DannyM]

Hi @ashtontito, we are still working on investigating this issue. If it isn't too much trouble, would you mind shooting us an email at support@airtable.com (with ATTN "Danny DSE") so that we can request some more diagnostic details? If possible, we'd like to see a screen recording of your browser's Developer Network tool while you are experiencing the problematic OAuth integration redirect. After investigating, hopefully we can share a fix ETA with you soon! Thank you.

[Risner]

+++++1. We need this and are experiencing the same issues. @ashtontito I found this article from ProBackup and their flow appears to work, while ours does not. Not sure if this is helpful, but it at least gave me hope that this should be possible and someone may have figured it out. 

[Emma_Yeap]

Hi @ashtontito @Risner ,

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.

[Emma_Yeap]

Hi again @ashtontito @Risner - updating to let you know that we have fixed this issue and you no longer need to URL-encode parameters as a workaround.

[Risner]

Thank you!