In 2020, we in the Core Platform Team forked the thephpleague/oauth2-server package as wikimedia/oauth2-server to incorporate changes while waiting for upstream. They don't seem likely to necessarily include these changes (and one has been declined already), so we need to decide on a longer term solution.
Relevant PR:
WE would now require https://github.com/thephpleague/oauth2-server/pull/1138 as well. See T261428 for details.
Which got declined.
https://github.com/thephpleague/oauth2-server/pull/1122 has had no movement...
Then there's also been some more releases, which our fork doesn't (currently) implement)
https://github.com/thephpleague/oauth2-server/releases/tag/8.2.0
https://github.com/thephpleague/oauth2-server/releases/tag/8.2.1
https://github.com/thephpleague/oauth2-server/releases/tag/8.2.2
https://github.com/thephpleague/oauth2-server/releases/tag/8.2.3
See also T270595: Update league/oauth2-server fork, and update in MW Vendor...
https://github.com/thephpleague/oauth2-server/releases/tag/8.2.4 is out now too
Still no apparent progress on the upstream... This is going to become a maintenance burden, and at some point the risk assigned may need to be increased
wWhile https://github.com/thephpleague/oauth2-server/releases continues to progress and divert from our fork...
As they're not going to accept our patches... Is there any way we can use OOPS-y type practices to create a sub library (or similar) and do our changes, overrides etc in there, rather than having to patch the code itself?
Or similar, if they won't add our features, see if they can add hooks/similar for us (if they don't exist already?) to do ours
https://github.com/thephpleague/oauth2-server/pull/1122 still looks like it could still get accepted, eventually... And is the more complex work.
https://github.com/thephpleague/oauth2-server/pull/1138 is not going to be
The other option is to fully fork it. Change the name, update the readme, register it in packagist.
+1, even as a temporary solution that would be an improvement IMO. The current situation is confusing, this is the only mediawiki/vendor package that uses commit pinning, the syntax for which isn't really intuitive - that just caused an outage (T321160).
There is apparently an OAuth-specific JWT spec now, which matches envoy's expectations. I left a comment in #1137.
(Also, as pointed out in that discussion, we could just override the behavior in a subclass.)
As API Gateway is nowadays owned by serviceops, adding the serviceops project tag to open API Gateway tasks tagged with the deprecated/archived "Platform Team Initiatives (API Gateway)" tag at https://phabricator.wikimedia.org/project/profile/4321/, as part of Phabricator Housekeeping.