Page MenuHomePhabricator

OAuth 2.0 access tokens have effectively infinite expiration date
Closed, ResolvedPublic

Description

Set expiration period for OAuth 2.0 access tokens to 4 hours using the $wgOAuth2GrantExpirationInterval configuration parameter in the OAuth extension on meta.wikimedia.org.

Background

Our OAuth 2.0 tokens are configured to expire in the very far future (about 292,277,000,000 years in the future).

This isn't a problem for APIs implemented in MediaWiki, since they can do an additional check in the database that the token has not been revoked by the user.

This isn't acceptable for APIs implemented in NodeJS or another system, which depend on the JavaScript Web Token (JWT) data to tell if a token is expired. If access tokens have infinite expiration dates, the user could revoke access, but the app could still keep using the JWT to call a NodeJS-based API, and everything would keep working.

Right now, the only API that's exposed through the API gateway that isn't in MediaWiki is Wikifeeds, which doesn't use the JWT. But future ones might.

OAuth 2.0 has a mechanism to require refreshing a token on some period. We should choose a refresh period that is more bounded, and that balances the hassle of having to refresh tokens with the risk of using a token that's been revoked. Somewhere between 1 hour and 1 day is probably reasonable.

I need to investigate the refresh period of some other services to see what's typical for OAuth 2.0 use.

Event Timeline

eprodromou added subscribers: Clarakosi, BPirkle.

@BPirkle and @Clarakosi can you validate that I captured this issue correctly?

I think it's probably good to get everyone thinking about refresh tokens now. If it were me, and I saw the expiry was virtually infinite, I probably wouldn't bother implementing the refresh token logic.

Looks good.

In addition to reconsidering expiry values going forward, we should consider what happens to existing clients that have already been issued (effectively) infinite access tokens. If we introduce a future service that does not bootstrap mediawiki and it is presented with an "infinite" token, how does it respond?

As usual there's a whole spectrum of how aggressively we could handle this, and how sophisticated we could make the associated logic. One of the more aggressive possibilities would be to simply refuse to honor such tokens. We only have 110 OAuth2 clients currently registered on metawiki, and I'd speculate that many of those have been created by people working on the API Gateway project. So if we make changes to expiry before the API Gateway release, it may be a fairly limited set of clients that would be affected.

@eprodromou Thanks for filing this so quickly! I think it correctly captures the issue at hand. And just a note that Envoy also validates tokens by checking the signature and making sure it hasn't expired so it also wouldn't be aware if a token was revoked.

Also, I'm adding @ArielGlenn so they can follow along.

@apaskulin asked what the default expiry should be.

  • Access tokens for owner-only keys should remain effectively infinite. We don't have a mechanism to refresh them now, so let's keep them infinite and we can loop back to finding a way to expire them at some future time.
  • Access tokens for the regular authorisation flow need to have a balance between dealing with the hassle of refreshing the access token, and the risk of letting an app continue to use a token that has been withdrawn. Let's set 4 hours as the arbitrary boundary for now, and we'll revise that as we get more usage information from developers. That should be long enough that most interactive user sessions won't need to use the refresh token, and short enough that revoking a token will make it effectively unusable "pretty soon".

I added T268284 to capture the need to have a refresh mechanism for owner-only api key auth tokens. I don't think it's urgent but I wanted to make sure we remembered.

To clarify, we could use $wgOAuth2GrantExpirationInterval to change the expiry for all access tokens, but that'd also change owner-only ones. I have not tested this, so maybe I'm wrong. But if that's correct, then we need to:

  • introduce a way to separately set owner-only access token expiry vs. all other access token expiry (code change)
  • make non-owner-only access tokens expire in some non-infinite timeframe (4 hrs sounds fine for starters), while leaving owner-only access token expiration at "infinity" (config change).

@BPirkle, The documentation for $wgOAuth2GrantExpirationInterval says, "Does not apply to owner-only clients, whose access tokens are always non-expiring.", so I assumed it wouldn't apply to owner-only clients. Seems like this was added by Cindy back in January.

Oh, awesome. Guess I should have read that. :-)

Given that, we just need the config change.

apaskulin raised the priority of this task from Medium to High.Nov 23 2020, 8:08 PM

Change 643727 had a related patch set uploaded (by Vlad.shapik; owner: Vlad.shapik):
[mediawiki/extensions/OAuth@master] Expiration date: OAuth 2.0 access tokens have effectively infinite expiration date

https://gerrit.wikimedia.org/r/643727

Change 643727 abandoned by Vlad.shapik:
[mediawiki/extensions/OAuth@master] Expiration date: OAuth 2.0 access tokens have effectively infinite expiration date

Reason:

https://gerrit.wikimedia.org/r/643727

Change 644056 had a related patch set uploaded (by Vlad.shapik; owner: Vlad.shapik):
[operations/mediawiki-config@master] Expiration date: OAuth 2.0 access tokens have effectively infinite expiration date

https://gerrit.wikimedia.org/r/644056

Change 644056 abandoned by Vlad.shapik:
[operations/mediawiki-config@master] Expiration date: OAuth 2.0 access tokens have effectively infinite expiration date

Reason:

https://gerrit.wikimedia.org/r/644056

Change 644203 had a related patch set uploaded (by Vlad.shapik; owner: Vlad.shapik):
[operations/mediawiki-config@master] Expiration date: OAuth 2.0 access tokens have effectively infinite expiration date

https://gerrit.wikimedia.org/r/644203

Change 644232 had a related patch set uploaded (by Vlad.shapik; owner: Vlad.shapik):
[operations/mediawiki-config@master] Merge branch 'master' of ssh://gerrit.wikimedia.org:29418/operations/mediawiki-config into T265075-oauth-2-0-access-tokens-have-effectively-infinite-expiration-date Change-Id: I2dafc28b3411da8dc09925ad496e9a890660720f

https://gerrit.wikimedia.org/r/644232

Change 644232 abandoned by Vlad.shapik:
[operations/mediawiki-config@master] Merge branch 'master' of ssh://gerrit.wikimedia.org:29418/operations/mediawiki-config into T265075-oauth-2-0-access-tokens-have-effectively-infinite-expiration-date Change-Id: I2dafc28b3411da8dc09925ad496e9a890660720f

Reason:

https://gerrit.wikimedia.org/r/644232

Change 644203 abandoned by Vlad.shapik:
[operations/mediawiki-config@master] Expiration date: OAuth 2.0 access tokens have effectively infinite expiration date

Reason:

https://gerrit.wikimedia.org/r/644203

Change 644236 had a related patch set uploaded (by Vlad.shapik; owner: Vlad.shapik):
[operations/mediawiki-config@master] Expiration date: OAuth 2.0 access tokens have effectively infinite expiration date

https://gerrit.wikimedia.org/r/644236

Change 644236 merged by jenkins-bot:
[operations/mediawiki-config@master] Expiration date: OAuth 2.0 access tokens have effectively infinite expiration date

https://gerrit.wikimedia.org/r/644236

Verified in production. Thanks, Vlad!

...
"expires_in":14400,
...