Authentication with Oauth 2.0
Will there be any ability to do 3rd party authentication with Oauth 2.0, or will it remain in Oauth 1.0a?
There is now an OAuth 2.0 beta available for v2 endpoints.
Igor Brigadir commented
I strongly agree, i suggested this before in the forums and it was also posted in Labs suggestions and acknowledged, but there was no update beyond that https://twitterdevfeedback.uservoice.com/forums/921790-twitter-developer-labs/suggestions/37637938-twitter-should-provide-more-granular-app-permissio
If you perfect person and you never did something wrong you can do whatever you want only remember every activity came the consequences
Oisín Moran commented
I'm currently looking to make something that only needs access to updating one thing in the profile settings (a user image) yet to do this, the permissions request the end user sees is:
- **This application will be able to:**
- See Tweets from your timeline (including protected Tweets) as well as your Lists and collections.
- See your Twitter profile information and account settings.
- See accounts you follow, mute, and block.
- Follow and unfollow accounts for you.
- Update your profile and account settings.
- Post and delete Tweets for you, and engage with Tweets posted by others (Like, un-Like, or reply to a Tweet, Retweet, etc.) for you.
- Create, manage, and delete Lists and collections for you.
- Mute, block, and report accounts for you.
But all I want is the "Update your profile and account settings." permission, I do not need or want anything else. I feel allowing such granularity would greatly enhance security (apps only asking for what they need), engender more trust, and increase the conversion rate for people signing up to apps developed for the Twitter platform.
Rahul Ganju commented
OAuth 2.0 is a complete rewrite of OAuth 1.0 from the ground up, OAuth 2.0 is not backwards compatible with OAuth 1.0 or 1.1, and should be thought of as a completely new protocol.
OAuth 2.0 is definitely an improvement over its arcane predecessor. Instances of developer community faltering while implementing the signatures of 1.0 are not unknown. OAuth 2.0 also provides several new grant types, which can be used to support many use-cases like native applications, but the USP of this spec is its simplicity over the previous version.
There are a few loose ends in the specification, as it fails to properly define a few required components, the big one -Security
Security: The spec just "recommends" the use of SSL/TLS while sending the tokens in plaintext over the wire. Although, every major implementation has made it a requirement to have secure authorization endpoints as well require that the client must have a secure redirection URL, otherwise it will be way too easy for an attacker to eavesdrop on the communication and decipher the tokens.
I advise you to implement as soon as possible a system that foresees the selection of the required permissions based on the actual use of your API. Otherwise you lose implementations and developers lose users. Hope you follow the advice soon
To add to the original suggestion, the permissions required for "Hide Feature" recently announced should be also as atomic as possible: https://twitterdevfeedback.uservoice.com/forums/921790-twitter-developer-labs/suggestions/39308614-make-permission-for-this-as-atomic-as-possible
Please make permissions required for Hide Replies API calls as atomic as possible.
Mass users are reluctant to allowing any write, and often read permissions. This is major stopper for Blocktogether.org broader adoption, for example.
Jon Ogle-Barrington commented
I also consider this to be a critical improvement to the platform
Alex Wait commented
I would consider this a critically needed improvement for effectively supporting Twitter on various platforms considering the permissions dialog is 100 times scarier for the average user now since the expanded dialog was released. We only need say follow permissions + bio but have to request the world because of the write permission needed. I like how we can go down to read only if needed but that's often not sufficient either.
It would also be very useful to be able to use the Account Activity API without DM permissions and just not send that information in the callbacks.
Igor Brigadir commented
I also like the idea of giving users control over denying permissions selectively - similarly to how Android apps work - apps must explicitly declare permissions, and users are free to accept or deny them - it is up to the app developer to turn app functionality off if permissions are revoked or denied (eg: chat app still works even if you deny permissions to contacts etc.)
Thanks for this additional information. Have you heard of OIDC and what are your thoughts on this?
Terence Eden commented
I like the way Mastodon does it. As a developer, I can be quite explicit in wanting to post on behalf of the user, but not alter their bio etc.
Similarly, as a user, I should be able to "untick" a permission requested by a developer.
Luca Hammer commented
The current write access stops me from exploring ideas with mute- and blocklists. Most people aren't comfortable with giving full access and my idea doesn't need it. This idea would improve the situation.
Twitter currently offers three levels of app permissions: (1) read only; (2) read and write; (3) read, write and access Direct Messages. These options are not granular enough for some developers, and developers would like more options to choose from.
For example, an app’s “write” permission could be segmented into more granular options: (1) write access to a user’s profile; (2) write access to a user’s network (follow/unfollow, mute, block, list modification); (3) write access to a user’s timeline, including the permission to Tweet, Retweet, or like a post.
Another example includes Sign In With Twitter: there could be an option to implement the sign in flow with “read” access only.
Here’s one example of a past forum post with a related request: https://twittercommunity.com/t/suggestion-more-granular-read-write-app-permissions/121810