Page MenuHomePhabricator

OAuth sometimes stops providing tokens for a user, even though the app was not deauthorized
Open, Needs TriagePublic


It seems that OAuth authorization sometimes expires, and csrf tokens are not longer returned when requested until the user reauthorizes the app.

If that is intentional (hopefully not), I have not found any documentation about the circumstances under which to expect that.

Event Timeline

Ragesoss raised the priority of this task from to Needs Triage.
Ragesoss updated the task description. (Show Details)
Ragesoss added subscribers: Ragesoss, Jdforrester-WMF.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 28 2015, 11:18 PM
Tgr added a subscriber: Tgr.Jul 29 2015, 12:02 AM

I might misunderstand what you mean, but refusing OAuth-authorized requests after the authorization has expired is kind of the point of having an expiration time.

What is the expiration time, and where is it documented?

Sitic added a subscriber: Sitic.Jul 29 2015, 12:32 AM
Tgr added a comment.Jul 29 2015, 12:54 AM

Sorry, I thought you were asking whether CSRF tokens should be exempt from expiration. I don't know if we expire OAuth authorizations. At a glance we don't seem to.

Likewise, I didn't actually run into the problem described. My proposed (ie, local dev) OAuth consumer had expired. Although @Jdforrester-WMF says that the described problem happens to him sometimes.

Tgr added a comment.Sep 9 2016, 2:00 AM

@Jdforrester-WMF have you run into this recently? Expiring proposed-but-not-approved consumers is intentional (although I think we could get rid of it; see T103587#2621901), if approved consumers expired as well, we would have more reports by now, I think.

It's not happened again recently, no.

Tgr closed this task as Invalid.Sep 9 2016, 6:24 PM

I'll assume this was some misunderstanding or some old bug that accidentally got fixed, then. Please reopen if you encounter the issue again.

@Tgr: periodically sees this, I think. I have logged 58 users who have at some point hit mwoauth-invalid-authorization. These are logged in users, so they must have authorized the dashboard at some point. The most recent case I have of this is from Tuesday, September 6. I would be very surprised if many — if any — of these users had de-authorized the app themselves, unless there is a way to do that besides going through "Manage connected applications".

@Tgr looking over the last few, these were accounts created recently, so the error couldn't be explained by the many-months-ago switch to a new OAuth consumer. If it's helpful, I could provide usernames and/or timestamps.

Tgr reopened this task as Open.Sep 9 2016, 7:01 PM

Yes, that would be helpful, thanks. Also, do you have the full error message? mwoauth-invalid-authorization is a catch-all message that takes the more detailed error message as a parameter.

T106066 is a known source of occasional mwoauth-invalid-authorization errors.

The error message is "The authorization headers in your request are not valid: No approved grant was found for that authorization token."

Here are some recent instances:

time it reached my logs: Sep 6, 2016 5:37:42 PM UTC

time it reached my logs: Sep 1, 2016 7:21:17 PM UTC
Tgr added a comment.Sep 9 2016, 8:40 PM

The authorization timestamps are 20160805190815 and 20160826155432 respectively, so (assuming those users would have reported by now if they were still unable to use the to tool) it seems like this was a one-time failure and did not require reauthorization. The error message mwoauthdatastore-access-token-not-found is only used when the auhorization record is not found in the database, or does not match the consumer. So in theory this could be some client-side error/tampering like T103023 but that seems pretty implausible... other than that I can't really imagine how it could happen. Weird.

Can you ask those users whether they remember anything strange?

Tgr added a comment.Sep 9 2016, 8:48 PM

assuming those users would have reported by now if they were still unable to use the to tool

Or maybe not. We seem to hit that error a dozen times an hour, according to the logs. Unfortunately we are not recording any useful information about it.

These actions would not have surfaced anything to the users at the time they failed, except that they would have been prompted to log in again.