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.
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.
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.
@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.
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: dashboard.wikiedu.org 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.
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:
User:MeganPeiser time it reached my logs: Sep 6, 2016 5:37:42 PM UTC User:Prof.bgreg time it reached my logs: Sep 1, 2016 7:21:17 PM UTC
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?
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.