Systemic failure in handling of OAuth revocations
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical System Image |
New
|
Undecided
|
Unassigned | ||
YouTube Scope |
New
|
Undecided
|
Unassigned | ||
ubuntu-system-settings-online-accounts (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
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:/
YouTube scope is authenticated
Something weird happened
ERROR: HTTP request timeout
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.