Support app-only authentication

[ryangreenberg]

Allow twurl to make OAuth 2 app-only requests as described at https://dev.twitter.com/docs/auth/application-only-auth.

[ryangreenberg]

I'm happy to work on this feature if I can get some input on the interface. Here's what I'm thinking:

• Add an --app-only flag which makes the request app-only instead of user-based.
• When making an app-only request, if no bearer token is available for the currently selected client application, fetch a bearer token from https://dev.twitter.com/docs/api/1.1/post/oauth2/token. Make this call using the consumer_token and consumer_secret from ~/.twurlrc for the currently selected client. Store it in ~/.twurlrc as a bearer token for the client application.
• Make the requested call providing the bearer token in the authorization header.

Some weird things I'm not sure about:

• making two requests for one twurl command the first time you need to get a bearer token
• what do you do when a bearer token is revoked?

[sferik]

Interesting idea. I’ve added support for application-only authentication in the twitter Ruby gem but didn’t consider adding it to twurl.

I’d like some more time to think about the interface but my initial reaction is that it should be part of the authorization/account flow, not necessarily specified with each request. For example, you could authorize with just a client ID/secret and the set that as the default account. This would fetch a bearer token and write it to your .twurlrc file. That should solve the first weird thing. As for the second weird thing, if we take this approach it would require the user to reauthorize upon revocation, so the flow would be:

1. Make a twurl request.
2. Get a 401 Unauthorized response.
3. twurl authorize
4. GOTO 1

In practice, I think this would be quite uncommon, since bearer tokens never expire, so it would only be necessary if the token is manually revoked.

One unsolved problem of this approach is how to distinguish between application-authenticated clients and user-authenticated clients in the twurl accounts view and how to switch between them, since you could have the same client ID associated with both. I think this is a solvable problem but it could make things more confusing.

What‘s your use-case for this? I think that would help drive the design.

[ryangreenberg]

Thanks for your thoughtful suggestions, @sferik. As you know from https://github.com/sferik/twitter, there are some endpoints that have higher rate limits when you use app-only auth, and there are other endpoints that only allow app-only auth.

I'd like to be able to give people instructions on how to use these endpoints using twurl as part of the working examples. Ideally it would be:

• clear to the user that they are making this request in a different way (given the different rate limits, etc.)
• easy to switch being making a request using app-only or normal user-based OAuth

These were part of my motivation for suggesting a flag (clearly part of the command, easy to add or remove), but your alternative has some of its own merits.

Another idea I had is to introduce a command that gets bearer tokens, which are stored on a per-app basis in .twurlrc. When you make a request with --app-only it uses the bearer token for the currently active client application. If none is available, the program exits with instructions on the authorization command.

[sferik]

Another idea I had is to introduce a command that gets bearer tokens, which are stored on a per-app basis in .twurlrc. When you make a request with --app-only it uses the bearer token for the currently active client application. If none is available, the program exits with instructions on the authorization command.

I like this proposal. I think it addresses both of our concerns. Just to make sure I understand it, I’m going to restate it as an example flow:

$ twurl '/1.1/users/show.json?screen_name=sferik'
{"id":7505382,"id_str":"7505382","name":"Erik Michaels-Ober","screen_name":"sferik","location"…}
$ twurl --app-only '/1.1/users/show.json?screen_name=sferik'
ERROR: Missing token for application-only authenticated requests. To fetch a token for this application: twurl token --consumer-key key --consumer-secret secret
$ twurl authorize --bearer-token --consumer-key key --consumer-secret secret
Authorization successful
$ twurl --app-only '/1.1/users/show.json?screen_name=sferik'
{"id":7505382,"id_str":"7505382","name":"Erik Michaels-Ober","screen_name":"sferik","location"…}

In the twurl accounts view, should there be some way to indicate that an account does (or does not) have a bearer token?

[mdeschamps]

hey guys,

sorry I missed this thread, @arturadib just pointed it out. I submitted a PR to support app-only auth. (#48)

It is quite a diff approach, instead of using --app-only per request, I set the app-only during the authorization and a 'app-only' profile is created. That way you can keep the same interface to set accounts, default and requests.

I am happy to help with either way as long as we get this guy shipped! :)

[AminBK]

In version 0.9.3, how do I get the app-only? I see the commit below, but from latest master branch, I cant see this commit. How do I go about to have a twurl with app-only option available? What will happen with the pull request?

c4fb7c2

btw, I'm installing with "gem install ruby". this is in windows

[andypiper]

@ryangreenberg any thoughts on completing this implementation... or helping to wrangle the options above? 😃

[devdazed]

its been over 5 years, any chance this will get added? is there a workaround for this?

[smaeda-ks]

I'm trying to get this done: #132

Any comments/ideas are welcome.

[smaeda-ks]

https://rubygems.org/gems/twurl/versions/0.9.5
We've published a new version, closing.