Due to limitations of how much we can control access tokens, we have decided in T394012: Decide how to expose session information outside of MediaWiki not to emit session information for OAuth 1 requests, and to accept emitting stale session information for OAuth 2 owner-only requests. To reduce the impact of this, we can emit a JWT session cookie for such requests. OAuth clients might ignore Set-Cookie headers, but some might not, and there's no harm in trying.
Unfortunately we'll probably not be able to fully reuse the mechanism created in T415007: Login with `action=login` and bot password does not create a JWT session cookie as cookies are normally set during persist(), calling that also saves the session to the session store, OAuth sessions are usually not persisted (the access token includes all necessary information, so the session store is only needed if something in the application needs to store its own session data, and almost nothing needs that), and we want to keep it that way as otherwise we'd do a session write on every request from clients which ignore cookies. We'll need to directly set/unset the cookie instead of using the needRefresh mechanism. We don't have a great place for doing that, currently. Maybe we'll need a callback that tells the session provider that it now owns the session.
One potential concern is cookie conflict - we probably want to use the same cookie name for all session types, to keep the Envoy logic simple. But that means that for a client using multiple session types (e.g. a browser that does normal cookie-based sessions but also OAuth), the various session handlers will write the same cookie. I think that won't be a problem as long as they use the same user, as the JWT contents will be roughly the same. In any case, using OAuth in the browser doesn't really make sense for OAuth 1 nor for owner-only consumers.