Add OAuth 2.0 Token Exchange (RFC 8693) to the supported OAuth flows

[cayetanobv]

This adds a tokenExchange flow to the OAuth Flows Object, as suggested by @ralfhandl in discussion #4807: a new fixed field tokenExchange, with tokenUrl required and scopes behaving as for all other flows. It follows the pattern the deviceAuthorization flow established in 3.2.0, including the validation schema addition and test fixtures (schema tests pass, 99/99).

Motivation: RFC 8693 token exchange is widely deployed (cloud STS endpoints, credential vending in data platforms), but until now there was no way to describe such an endpoint in an OpenAPI document — clients always knew it out of band (SDKs, hardcoded config). The concrete need driving this: geospatial data catalogs (STAC), where generic clients discover APIs at runtime from description documents and need to know where to exchange an identity token for scoped storage credentials. The STAC Authentication extension (which follows OpenAPI's security schemes) plans to mirror this flow once it is drafted here — see the discussion with a STAC Authentication maintainer in portolan-sdi/portolan-cli#551.

Deliberately minimal: no description fields for subject_token / requested_token_type etc. — those are runtime request parameters defined by the RFC, not description-level configuration, mirroring how the device flow's spec text doesn't describe device_code.

• schema changes are included in this pull request

Remark: Per the project AI policy, AI tooling was used for research and drafting; I reviewed and take responsibility for all content.

Thanks!

Cayetano Benavent.

[handrews]

@cayetanobv We will definitely look at this for 3.3, but there are two major things in flight that will need to settle first (just so you understand we're not ignoring you):

• We are moving security features out into their own specification in a separate repository so that we can make changes in this area more rapidly. So at some point, this work will need to be moved over to the appropriate repo, which is not yet set up.
• We are also considering some larger changes to how we handle security, which might impact the approach here. While there is a GitHub discussion on this, it is lengthy and there is a new proposal being written that will more directly summarize the intention. This could lead to an entirely new security approach alongside the existing one, or it could be (like this PR) an enhancement of what we have. We don't really know yet.

Things move rather slowly during the summer so it might be a while before we get to this, but we will respond once these other things are more clear.

[handrews]

I converted this to a draft just to keep it out of our active todo list for now. We will revisit all open security concerns once the other things settle.

[cayetanobv]

Thanks @handrews, I'm glad to see the progress you're planning on security. I'd be happy to contribute to the new repository if you need any help. While you decide how to proceed with the outstanding security tasks in OpenAPI, we'll continue our authentication work on the STAC Authentication Extension and the Portolan project:

stac-extensions/authentication#44

portolan-sdi/portolan-cli#551