API Endpoint For App To Revoke Access Token

mikabrown · 2012-08-17T01:37:42.000Z

With the API 1.1 caps on total number of users for an application, please give us an endpoint where the application can do housekeeping and remove itself from Twitter accounts that don’t actively use the application any longer.

It will be quite unfair to count into the 100,000 limit Twitter accounts that don’t use the application any longer. For example, someone authorized the application, checked it out for a day, decided it’s not what they needed, but never removed the application from their Twitter account. That inactive user is going to forever count as one of the 100,000 until you provide the application with the means to remove itself from Twitter accounts.

Alternatively, put time limits on access tokens, with an easy and automated way to refresh an access token, the way Google is doing. That way the expiry of access tokens will do the housekeeping task of cleaning out inactive users.

jerrylthompson · 2012-08-17T12:40:54.000Z

+1 - I mentioned this very thing under a separate thread. There are active users and passerby users, which as you mentioned, may have authorized your app once but never used it again without being able to cycle through the number of tokens whether they expire after a set period of time of no API calls reseting the timer on the token or being able to proactively deauthorize tokens means that every single app will eventually hit their limit and fall off.

richardhyland · 2012-08-17T14:50:02.000Z

+1 I agree with this. Automatically expiring tokens that haven’t made an API call for a certain period of time

lovebug86400 · 2012-08-28T03:44:55.000Z

+1 agree. any official response from twitter?

LeonardoBollini · 2012-08-29T21:26:45.000Z

+1 I agree

aaronhill6 · 2012-10-11T16:30:38.000Z

I don’t know what’s more unbelievable: that there seriously isn’t a way to do this, or the fact that this thread has gone > 7 weeks with no response from Twitter… It’s almost not even worth integrating with them at this point…

kurrik · 2012-10-11T21:35:02.000Z

We’re considering solutions here. It would be rather difficult to provide a revoke token API, since an app could use that to circumvent token limits (which ONLY apply to client-type apps, by the way).

A solution here would probably look more like inactive tokens expiring over time. There’s nothing official to announce at this time though.

jerrylthompson · 2012-10-11T21:49:37.000Z

For the client apps which still exist, being able to revoke tokens when they are not being used is rather important.

Are photo sharing services which both handle login authentication directly as well as through oAuth Echo considered client-type apps?

Also, is there a way to find out exactly (or approximately) how many tokens an app has out there?

kurrik · 2012-10-11T21:58:30.000Z

Apps subject to the 100,000 token limit are more rigorously defined in the API Terms document.

We currently do not offer a way for apps to determine how many tokens they have allocated.

digitalpoint · 2012-10-21T05:32:30.000Z

+1 for being able to revoke tokens. Not because I think we are in danger of hitting the token limits, but simply because I’m anal retentive and like to keep things clean. If a user unlinks their Twitter account on our end, the inability to revoke the token always seemed silly to me.

As an end user, I hate the fact that I can unlink my Twitter account from within someone’s app, but there’s no way to know if they really forgot my credentials without manually going to Twitter’s website to revoke it.

jublonet · 2012-10-22T10:34:36.000Z

We currently do not offer a way for apps to determine how many tokens they have allocated.

While exactly this would be necessary.

ReclipperApp · 2013-07-19T11:25:44.000Z

This thread is rather old. +1 for answer if this was somehow resolved (according to docs, was not), and +1 for way to do that.

If you’re worried about quota work around, maybe make tokens revoked by API still count to your quota for some time period (e.g. 1 week). That way, the apps won’t be able to authorize user for a short time and then de-authorize him and standard apps will be able to de-authorize old users.

IHVN · 2013-10-02T13:40:05.000Z

+1

normxl · 2014-05-01T00:01:32.000Z

+1

tal_asad · 2015-12-04T13:56:25.416Z

+1

Maybe add a few api_endpoints to handle this sort of functionality. One to get how many users have granted access to your apps, one to revoke access to users and one to list inactive users?

I think its fair in oauth workflow for apps to be able to revoke access to users who do not fall in the common use-case.