xdevplatform
Twitter API OAuth 2.0 - CORS / Postmessage
Hey guys,
We are currently working on implementing the Twitter API v2 and would like to authorize via the new OAuth 2.0 Authorization Flow.
Pretty much all OAuth Flows of other sites allow an in-browser callback, either by passing redirectUri="postmessage" in case of the Google Login, or by tracking the OAuth window via window.open and then checking if the URI has changed to grab the auth code from the params. This is import to give the user immediate feedback if the authorization was successful or not.
Unfortunately it looks like Twitter doesn't allow either of these methods, and blocks any tracking of the opened authorization window via its CORS policy. While I completely agree that the CORS policy should be in place for any other API call (in order to prevent clients from calling the API directly within the browser), I definitely think that it should be loosened for the authorization endpoint (https://twitter.com/i/oauth2/authorize).
It's taken Twitter quite a while to step away from the outdated 3-legged auth flow, so it's pretty important to the get the OAuth 2.0 flow implemented properly so that developers can access it easily. So far there is no single gem out there that helps to implement the OAuth 2.0 flow for Twitter, simply because there is no good option to have a direct callback. Please consider allowing this to work the same like all other services.
Thank you for the feedback!
I can confirm that Twitter currently does not allow any API endpoints to be called from the client via the CORS policy, and that this has been unchanged for a very long time (10+ years). We’re always open to reconsidering the position, and this is something that we’ve had a lot of feedback on - as you noted, we’re in the process of bringing OAuth 2.0 across the new API, so this is all being thought about. No specific timing to share, though.
An overall change to the CORS position for the API as a whole will be beyond the scope of this single SDK, but thanks for raising. For now, you’ll need to implement on the server-side.
Thank you Andy,
I definitely think the CORS policy should remain, however it would be great to add a postmassage hook to close the authorization popup and pass the response to the original window.
As far as I'm aware both Facebook & Google handle it this way, which makes it easy to implement - and then the original Frontend can still forward the response to the server to exchange the code for an auth token.
I guess there will also be some sort of hook like that for the mobile SDK where the OAuth 2.0 flow does not appear to be working yet.
This is useful information, thanks for sharing the other implementations. Definitely all still in flux but we appreciate the input and data.
Bump
As mentioned above, there's no specific timing to share on a change here - you'll need to handle server-side.
Estimated to be another 10 years. https://stackoverflow.com/a/35898961/2602771
Please refer to the Code of Conduct for our OSS code projects, in particular the guidance around respect and patience.
I've previously stated that a change is actively under consideration at this time, and that it is beyond the scope of this single library to implement.
"me too" comments, or speculation about timescales, are not useful additions to this issue. Thank you.