Tell me more ×
Stack Apps is a question and answer site for apps, scripts, and development with the Stack Exchange API. It's 100% free, no registration required.
up vote 3 down vote favorite
2

Other that invalidating an access token doesn't remove the app from the apps tab (why not?) whats the difference between these two methods?

share|improve this question

1 Answer

up vote 3 down vote

I'm going to lay some ground work about authentication and access tokens before answering, because I think you have some misconceptions.

When a user authenticates an application they have given permission for it to access their data in certain ways (via scope). The actual mechanism* for accessing this data is an access token, but the authorization to get it is independent of the tokens.

Significantly, just because an application doesn't have any valid access tokens (for instance, they all could have expired) that does not mean the application is not authorized to access a user's data. Practically, this means that when the application next puts the user through a OAuth flow they will not be prompted to Accept/Reject the app; a new access token will just be given to them.

This is why invalidating a single access token doesn't remove the application from the apps tab, the application is still authorized. Additionally, an application can have multiple valid access_tokens for the same user.

To draw parallel's with another OAuth 2.0 implementation; Facebook's App Settings page behaves similarly. The Stack Exchange app used for login doesn't request perpetual access nor does it refresh access tokens, yet the app stays in the list long after all created access tokens must have expired.

enter image description here

So the distinction between these methods is:

  • auth-tokens/{tokens}/invalidate will destroy just the access tokens passed
    • the app will remain authorized, and any other access tokens it has for the user will remain valid
    • putting the user through an OAuth flow will skip all Accept/Reject prompts
    • the app accordingly remains in the user's apps tab
  • apps/{tokens}/de-authenticate will revoke authorization for the app altogether
    • any other access tokens attached to a user will also be destroyed
    • putting the user through an OAuth flow will force them to Accept/Reject the app again
    • the app is removed from the user's apps tab

Some use cases for /auth-tokens/{tokens}/invalidate:

  • an app is done with an access token, and doesn't want to be worried about it leaking
    • malice is rare, but there's a lot of incidental logging on the internet
  • an app needs an access token for more than 1 day (the default expiration) but not forever
    • that is, grabbing a token with scope=no_expiry and then expiring the token when done

The use case of /apps/{tokens}/de-authenticate is primarily allowing applications to implement uninstallation as part of the application. Without this method, developers would have to instruct users on how to reach the app tab and manually remove their apps. That'd be both bad UX, and rather brittle as any tweaks we made to the app tab would risk invalidating those instructions.

share|improve this answer
Thanks Kevin, sorry about not quite understanding this. One thing I still don't understand is that whats the point of invalidating an access token, if the app is simply given a new access token, the old one might as well be kept? – Jonathan. Dec 16 '11 at 18:18
Also if an app is given a new access token, how does the API know which user to give this access token for? – Jonathan. Dec 16 '11 at 18:19
@Jonathan - you invalidate an access token if you don't want to keep one on hand, think of how some companies make you re-enter a credit card # every time. You'd only have the access token when you're using it, basically. – Kevin Montrose♦ Dec 16 '11 at 18:21
@Jonathan. - the OAuth flow is always instigated by an application via a user's browser, the API identifies the user based on the credentials they present using it (cookies, global login, or OpenID). An app being authorized just means there's no prompt, the same method of identifying a user is used. – Kevin Montrose♦ Dec 16 '11 at 18:23
so it only applies to implicit flow? – Jonathan. Dec 16 '11 at 18:40
1  
@Jonathan. - the explicit flow gets access tokens as well, auth codes are just an intermediate step there. Both flows involve the user's browser and authorization as well. – Kevin Montrose♦ Dec 16 '11 at 18:58
I know, I mean after invalidating an access token, if it tries to access a method using an invalid access token, it will not just get a new access token. because the server is not storing the user's cookies, global login etc. – Jonathan. Dec 16 '11 at 19:03
@Jonathan. - using an invalid access token will always result in error, an app will have to run through the OAuth flow again to acquire a new one. There's no automatic creation of access tokens, regardless of the application style. – Kevin Montrose♦ Dec 16 '11 at 19:05
Ok so if an invalid Access Token is used, the API will return an error, it is then up to the app to run the user through the auth process again. The app does so, if the user is logged in already and the app is still authorised, the auth flow will invisibly use the cookies/local storage/etc, or otherwise present the OAuth dialog, right? If I've got that right then it make it much clearer so thanks :) – Jonathan. Dec 16 '11 at 19:34
@Jonathan. - yep, seems like you've got it. – Kevin Montrose♦ Dec 16 '11 at 19:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged