Discussion around the release of application-only authentication

episod · 2013-03-11T18:34:14.000Z

Hi Developers,

This thread is for the discussion of the recently released [node:15742, title=“app-only auth”].

First, some quick release notes:

An application may find repeated attempts to negotiate or invalidate a bearer token made forbidden by a HTTP 403. This limiting is intentional, but the threshold is far too low. We’ll be relaxing these restrictions over the next few days.
For now, use explicit “id” parameters with /statuses/show and /users/show – interpolated parameters are not yet supported when using this auth format on those methods. This will be resolved in the coming days.
[node:10280] has been upgraded to work with application-only auth. When accessed with an application bearer token, the indicated rate limits relate to the application-only auth context, denoted by the rate_limit_context/application node that appears instead of the rate_limit_context/access_token node you would find in user-based requests.
Similarly, X-Rate-Limit-* HTTP headers returned when accessing methods through app-only auth are also scoped to that authentication context
I wanted to reinforce that the limits assigned to the app-only auth context are completely separate from the limits assigned to user-based auth.
Rate limits in this context are associated purely with the application. IP addresses are not a factor in per-resource rate limiting in API v1.1.
App-only auth works only with API v1.1.
App-only auth requires SSL for all operations. Don’t cut corners. Verify peers.

Let us know if you have any questions or issues working with app-only auth. I think you’ll find it exceptionally easy to implement.

Thanks,
@episod

hugw · 2013-03-11T19:46:50.000Z

Hey @episod, i can’t access documentation, it says access denied.

episod · 2013-03-11T20:04:47.000Z

This should be resolved; thanks!

JoeMayo · 2013-03-11T20:24:26.000Z

Thanks for this. Can Application-Only be used for Streams too?

episod · 2013-03-11T20:26:05.000Z

Not at this time. It’s definitely something we want to support, but it will be an evolutionary process to get to a genuine application model in all aspects of the Streaming API.

JoeMayo · 2013-03-11T20:33:02.000Z

Looking forward to it. Just some feedback - most of my streaming implementations are application model.

JoeMayo · 2013-03-11T20:34:22.000Z

What type of assumptions should we make about the lifetime of a Bearer Token?

hugw · 2013-03-11T20:36:14.000Z

o/

episod · 2013-03-11T21:30:44.000Z

At this time, bearer tokens never expire on any kind of fixed or dynamic schedule. If you issue a request to invalidate a bearer token, the existing bearer token will cease working.

It’s a good practice to get in the habit of using oauth2/token every 15 minutes or so and issuing a request for a bearer token. If one is already negotiated for the application, the same token will be returned in the response. If it has since been invalidated, you’ll be awarded the new bearer token.

timwhitlock · 2013-03-11T21:55:19.000Z

I’m not finding it very easy to update my libraries with these 403s all the time. What’s the logic here? Does it reset?

JoeMayo · 2013-03-11T23:51:45.000Z

Docs seem to be out of sync with response format.

Instead of:

{“token_type”:“bearer”,“access_token”:“AAAA%2FAAA%3DAAAAAAAA”}

I’m seeing:

{“access_token”:“AAAA%2FAAA%3DAAAAAAAA”}

episod · 2013-03-12T00:20:07.000Z

We’re working quickly to better rectify this. Expect it to be considerably more reasonable by the end of the week. Thanks!

episod · 2013-03-12T00:20:21.000Z

Thanks for the feedback; we’ll look into what’s up with that.

episod · 2013-03-12T00:26:02.000Z

@kurrik’s Go library for the Twitter API now supports application-only auth. Take a look at this example if you’re interested: https://github.com/kurrik/twittergo/blob/master/examples/search_app_auth/main.go

Writing support for this form of auth is pretty trivial with most languages. If there’s a language you’d particularly like to see a sample of, let us know and we’ll see if we can help out.

JoeMayo · 2013-03-12T02:07:29.000Z

I just checked-in application-only auth in LINQ to Twitter too: http://bit.ly/ZvsNcs

timwhitlock · 2013-03-12T12:58:03.000Z

What’s the worst thing that could happen if someone published their bearer token into a front end JavaScript app? People will do this to fix their broken widgets when you finally switch off 1.0.

Assuming a read-only app. I guess someone could steal your rate limit allowance. But what else is at risk? and what is Twitter’s position on this practice?

episod · 2013-03-12T14:16:09.000Z

We don’t recommend including bearer tokens in public javascript, but don’t outright forbid it. It’s definitely a wiser approach than including consumer keys and secrets.

The worst case scenario is indeed that someone else will take your bearer token and exhaust your rate limits with it. Or otherwise be abusive to Twitter with it, causing your API key to potentially be suspended and any other fallout that goes along with that.

There could be additional implications as the capabilities of such tokens expand over time.

I would recommend that anyone going down this route did so in a way that allowed them to easily swap a compromised bearer token for a freshly negotiated one after using oauth2/invalidate_token.

I would not recommend this approach at all for a medium to high traffic web site – the rate limits are low enough that it is not feasible to use as a client-side solution for more than a small handful of simultaneous users.

140dev · 2013-03-13T00:13:04.000Z

I’ve read the docs, and it does look straight-forward. What I don’t understand is why application-only auth is necessary. Can you list the functional differences and benefits over single-user Oauth? Aren’t the rate limits the same and the functionality available to both largely the same? I can see that application-only auth is limited compared to single user OAuth, because there is no “user”. Therefore things like posting tweets and I assume following will not work with it. Are there any places in the API where application-only auth is better? Or is it only the increased simplicity of making the API call? As a trainer/writer my concern is when do I tell people to use this instead of single user?

episod · 2013-03-13T15:07:24.000Z

The first way I’d evaluate this is – is the API call being made on behalf of an end user or is it on behalf of the thing you’ve created? If it’s on behalf of the thing you created, and that thing is a website, a service, a cron job, a full-featured application – then app-only auth should be used. A user context should be used when there is a user. An application context should be used when there is not.

There are still times when an application may have a dedicated user account representing itself – a bot is a good example – it’s both a user account and an application. It needs to read a home timeline, or a mentions timeline, and issue tweets on its own behalf. It’s a non-human user.

When an API call is made using a user account, a story is being told through the vehicle of the identified application. That user retrieved this user’s timeline. That user looked up these 1,000 user IDs. That user searched for “North Korea.” If the story you’re telling doesn’t involve a user as an actor or character, then application-only auth should probably be used.

Another use case is as a sidecar pool to draw from when the per-user limits prove mildly inadequate for a timely operation.

In the future, applications may gain additional capabilities in the platform. Application-only auth will be how an application leverages these capabilities.

Some devs will use a mix of both kinds of auth. Many will just use one or the other.

140dev · 2013-03-13T15:26:56.000Z

Thanks. All of this is clear. I am now writing a book on Twitter OAuth. I will explain all of this in the chapter on application-only auth. I also have a chapter on Single-user OAuth, which has been a standard for years. I need to give people a clear answer to the obvious questions:
Why should I use application only auth instead of single-user OAuth?
Is there a reason to choose one over the other?
Are there any benefits of application-only auth over single-user?

Reading between the lines, which I understand, Taylor, you have to do sometimes :), I see this hint:
“In the future, applications may gain additional capabilities in the platform. Application-only auth will be how an application leverages these capabilities.”

So I guess we can conclude that programming with application-only auth is a path to the future of the API. We should program with it instead of single-user OAuth, when representing the app itself, because it will have future benefits?

Is that correct? That’s enough of a path for me. Thanks.