Fully adopt OAuth 2.0
I would like the Twitter API to use OAuth 2.0 instead of OAuth 1.0. OAuth1.0a is fairly specific to the Twitter APIs at this point in time. It's complicated to implement, and there is a dwindling number of developer tools that support it. OAuth 2.0 is less complicated and easier to build into an app than OAuth 1.0.
Marking as “closed” as we are unable to invest in fully migrating to OAuth 2.0 at this time.
We appreciate this feedback. This has been top of mind for us and we deeply understand the issues associated with OAuth 1.0. There are a number of constraints that prevent us from investing in fully migrating to OAuth 2.0 at this time. While this is not a change we expect to make soon, please keep the feedback coming so that we can document this well for the future.
Yuri Schimke commented
With ubiquitious HTTPS, the signing features of Oauth1 seem minimally useful. For developers on blessed platforms able to use TOO APIs, it doesn't matter as it's taken care of.
But overall Oauth2 just makes things simpler for everyone, both internal twitter API developers and especially for anyone implementing authentication for 3rd party clients.
But more than that, Oauth2 (or OIDC etc) is just how the world of APIs works externally. The expectation of every developer on the web is now that they can easily prototype some code by getting a temporary Bearer token and sending any sort of request to the API.
It must be a handbrake on interesting integrations for Twitter.
I've implemented Oauth for a large number of services, and Twitter stood out as the only really painful one https://github.com/yschimke/okurl/tree/master/src/main/kotlin/com/baulsupp/okurl/services/
Lorna Mitchell commented
Especially as the Twitter API changes seem to make it more modern, I'd expect to see a switch to OAuth2. OpenAPI Spec doesn't even have support for OAuth 1, it's not widely used at all any more https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#security-scheme-objectIMO the benefit of OpenAPI (users being able to import into Postman or quickly generate a wrapper for their preferred language) are lost and the majority of developers will be blocked by this OAuth1 hurdle (at least until the libraries catch up)