Systemic failure in handling of OAuth revocations

[dobey]

Current handling of OAuth tokens in the system is quite poor, especially in failure cases.

The way webapp authentication works via online-accounts, is a complete facade. The OAuth tokens are not even used, but instead the cookies are copied from the account plug-in's web view, and stored under ~/.config/ for the app. This means that when the cookies expire, and you still have an account configured you end up being presented with a logged out experience on the web site, depending on what URL is being used, and what site it is. For example, on Untappd, it has happened several times where, despite having my account existing and enabled in system settings, that upon opening Untappd, I have been presented with the page requiring me to log in. In Twitter, one is simply redirected to a fairly simplistic page requesting entry of username and password, with no explanation at all.

Conversely, if for these services, one does go to the site's settings page, and revokes access for the OAuth token, absolutely nothing changes. The online accounts UI does not pop up requiring one to log in again. The app will continue working just fine, until the cookies in question expire, the webapp's configuration is deleted, or the account is removed.

Furthermore, in scopes which do use the account, behavior is very unacceptable when a token is revoked/expired on the server side. For example, if one opens the YouTube scope, and logs in, everything seems to be fine. But if one goes to https://security.google.com/settings/security/permissions for the account in question, and revokes the token access for Ubuntu to use YouTube, the result upon refresh of the scope is a blank view. There is no way to log in again. There are no videos to watch. All that appears in the scope-registry.log for this situation is the following:

YouTube scope is authenticated
Something weird happened
ERROR: HTTP request timeout

[dobey (dobey)]

It should be said that currently the only reliable way to deal with these situations, is to delete the account and require the user to log in again. This is why the Ubuntu One account behaves this way.

I don't see a good solution to this, given the current design/architecture of online-accounts.

[Alberto Mardegan (mardy)]

There are two completely separate issues here:

1) The webapp authentication problem is real, and works exactly as you described. It's a trick to improve the first-time experience of the webapps, and it's not reliable in any way. However, let's discuss it in a separate bug report, please (we probably already have some bugs about that).

2) The Youtube authentication problem could be caused by the Youtube scope not properly handling the error from the remote server: youtube receive a cached token from OA, which most likely is getting refused by the server, but the scope doesn't handle the case properly.
The proper handling of this error would be invalidating the existing token (the OAuth plugin has a special ForceTokenRefresh option for this case).

I don't see how this is related to UbuntuOne in any way.

[Alberto Mardegan (mardy)]

Just found this (read near the bottom):
  https://gist.github.com/arirubinstein/fd5453537436a8757266f908c3e41538
It appears that Google might have an *undocumented* API to exchange an API token for a web session. I'm not suggesting that we use it, I'm just linking it here for reference.