OAuth 2.0 now ready to be implemented?

[florianmartens]

As far as I can tell, Twitter has launched its API v2 which fully implements OAuth 2.0 along with fine-grained permission management. There's currently no passport package supporting Twitter's API v2. The only issue concerning OAuth 2.0 and this package (#57 ) has been closed.

Is OAuth 2.0 still a possibility for this package? Is there anything standing in the way of the implementation?

[jaredhanson]

Can you point me to the documentation that indicates OAuth 2.0 is usable for user-based login flows? I looked the docs over, but as far as I can tell OAuth 2.0 only applies to client apps accessing the API directly, rather than on behalf of a user.

[florianmartens]

Hi @jaredhanson (thanks for your work btw. everything is super helpful). The way I understand the docs, the API provides user-based login flows using PKCE as explained here:

https://developer.twitter.com/en/docs/authentication/oauth-2-0/user-access-token

[florianmartens]

I would really love to know if this is something you could see yourself working on @jaredhanson? For my current app, I definitely need some sort of solution. And before taking a stab at implementing this myself using the generic OAuth2Strategy, it would be awesome to know if you or anyone else is working on this in parallel.

I'd be also hesitant to attempt releasing a package for this since the Twitter integration seems to be one of the most used and featured packages and I'm not very familiar with Passport yet.

I also dug a little deeper into the Twitter API and I think there should be nothing holding back the implementation from the Twitter API side, right?

I hope this doesn't sound like me "expecting" someone to work on this for my sake. Just want to check where people's heads are on the matter.

[jaredhanson]

In general, I don't make commitments as to if or when I will do open source work. That work is driven based on my own interests or needs.

I'm interested in seeing an OAuth 2.0-based Twitter strategy exist, but its not a high priority. Given the number of deployed OAuth 1.0 apps using Twitter, I don't see them dropping support for that anytime soon. And the OAuth 1.0 strategy is working just fine. My recommendation would be to move forward with that strategy. Is there functionality present in Twitter's OAuth 2.0-based APIs that can't be done via OAuth 1.0?

[florianmartens]

Absolutely no problem. I fully expect you to be a busy person and am very thankful for all the hard work you've already put into this library!

What you say is correct, but only holds true for apps that are already deployed using OAuth 1. Anyone implementing this today is very likely to search for an OAuth 2.0 solution.

My main motivation for wanting to implement Auth 2.0 is a general unwillingness to add sessions to my app for this library alone. On top, I appreciate the fine-grained control and advanced security that comes with OAuth 2.0. For any native client (not my use-case), PKCE is also a big plus. Finally, it's a pain to upgrade OAuth in production since all users must reacquire their tokens and have to be logged out.

That said, the Twitter API v2 supports both OAuth1 & 2 so the "functionality" should be the same.

In case someone else is also interested in seeing an OAuth 2.0 Passport integration for Twitter and could need my help or support in some capacity - feel free to reach out. I'm sure I'll take a stab at this at some point.

[jaredhanson]

Thanks for this feedback, it helps me understand the desire for OAuth 2.0. One thing I want to clarify, however:

My main motivation for wanting to implement Auth 2.0 is a general unwillingness to add sessions to my app for this library alone.

It is possible to use OAuth 2.0 without sessions (ie, disabling state), but doing so opens up a host of potential attack vectors, including CSRF attacks against your app's callback URL. I strongly advice against this, and recommend using proper state protection (which requires sessions) when deploying OAuth 2.0. I understand the desire to deploy with the latest protocols, but don't let this be a reason to not use OAuth 1.0.

[florianmartens]

@jaredhanson thanks. That is something I definitely have to take a look at. Thank you for the hint. This is something, I'm just getting a grip of.

I'll still be on the lookout for an OAuth 2.0 solution since I feel the other points I made are still valid. Especially when it comes to migrating in a production environment.

[fholzer]

Seems like the api call to /user/show.json made in the finalize callback is part of the "Follow, search, and get users" v1.1 API, which is now part of the "Elevated" level so some apps might not be able to use this strategy as it is right now.

Though this can be worked around by setting skipExtendedUserProfile: true in the options passed to the strategy.

[florianmartens]

Hi hi, here's my attempt at creating a passport strategy for the Twitter api (it works for my purposes). It's pretty basic at this point since the new Twitter API still has some limitations. E. g. it's currently not possible to retrieve the email address of the logged-in user (see here). I'll add some tests and an example to the package eventually.

Instead of implmenting OAuth with Passport, a good argument could also be made for not doing anything in the backend and using the PKCE flow for a public client.

https://github.com/florianmartens/passport-twitter-oauth2.0

[ooitanojohn]

Sorry, I was wrong