Request to add native support in Red Hat 3scale API Management for validating tokens obtained via OAuth 2.0 On-Behalf-Of (OBO) token exchange, aligned with RFC 8693.

Background / Current Behavior:

• 3scale APIcast currently validates a {}single JWT access token{} presented in the `Authorization: Bearer <token>` header, issued by an OpenID Connect IdP (e.g. RH‑SSO or RHBK).
• 3scale does {}not implement token exchange{}. Token exchange is handled by the IdP.
• RH‑SSO only offered token exchange as a tech preview (not supported for production).
• RHBK 26.2+ introduced {}Standard Token Exchange (V2){}, fully supported and aligned with RFC 8693.

Problem Statement:

Customers requiring both application identity (client credentials) and user identity (end‑user claims) cannot rely on 3scale alone.

• 3scale validates the client token but does not natively validate a user token in the same request.
• Workarounds include backend validation or custom APIcast policies, which increase complexity.
• Native support for OBO token exchange in 3scale would simplify architectures and align with modern OAuth2/OIDC practices.

References:

• [RFC 6749 §4.4 – Client Credentials Grant](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4)
• [RFC 8693 – OAuth 2.0 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693)
• [RHBK 26.2 documentation – Standard Token Exchange (V2)](https://docs.redhat.com/en/documentation/red_hat_build_of_keycloak/26.2/html/securing_applications_and_services_guide/token-exchange-_standard-token-exchange)
• [Red Hat KCS – Token Exchange support in RH‑SSO and RHBK](https://access.redhat.com/solutions/5445811)
• [3scale OIDC integration docs (2.15)](https://docs.redhat.com/en/documentation/red_hat_3scale_api_management/2.15/html/administering_the_api_gateway/integrating-threescale-with-an-openid-connect-identity-provider)

Requested Enhancement:

• Add native support in 3scale APIcast for validating tokens obtained via OBO token exchange.
• Ensure compatibility with RHBK’s Standard Token Exchange (V2).
• Provide configuration options to enforce policies based on both client and user claims in the exchanged token.