For some authentication flows (e.g. permanent owner-only tokens) we have two meaningful JWTs, one as a bearer token and one as a session cookie (see T418042). Before we combine the information from both tokens, we should make sure that they actually belong to the same user by comparing the sub claims. This is complicated by the fact that they use different formats, something that the gateway ideally shouldn't have to know about.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T399291 Epic: API Rate Limiting Architecture | |||
| Open | None | T412585 Epic: Enforce API rate limits (WE5.1.3c) | |||
| Open | None | T417779 rest gateway: enforce rate limits (stage two) | |||
| Resolved | daniel | T418042 rest gateway: use rlc from sessionJwt cookie even when a bearer token is used | |||
| Open | None | T418835 rest gateway: ensure sessionJwt matches bearer token |
Event Timeline
Comment Actions
The prefix of the sub claim reflects the default CentralIdLookup of the given wiki, it's not affected by what kind of session handler generated it. So for SUL wikis it's always going to be mw:CentralAuth::.
Comment Actions
...except for owner-only access tokens which do not use a prefix. But owner-only tokens are largely ignored so there shouldn't be anything needing to be combined in that case?
Comment Actions
I guess this is not really true since the sub is taken from the access token, so you could e.g. rotate access tokens to get around the rate limit.
We could always put the owner-only-compatible user ID in a separate field if that makes life easier. In theory, there can be conflicts for that since different wikis use different ID systems. In practice, now that Wikitech has been merged into the SUL cluster, all non-SUL Wikimedia wikis are closed-registration and too small to have much use of OAuth so no need to worry about conflicts.
Comment Actions
I'd say this is "nice to have". JWTs disagreeing on the user's identity should be rare, and the security impact is low.