The Authentication/Proxy service has a name - Security Token Service (STS). oAuth token exchange working draft has a good summary of STS and its purpose:
A Security Token Service (STS) is a service capable of validating
security tokens provided to it and issuing new security tokens in
response, which enables clients to obtain appropriate access
credentials for resources in heterogeneous environments or across
security domains.
Web Service clients have used WS-Trust [WS-Trust]
as the protocol to interact with an STS for token exchange. While
WS-Trust uses XML and SOAP, the trend in modern Web development has
been towards RESTful patterns and JSON. The OAuth 2.0 Authorization
Framework [RFC6749] and OAuth 2.0 Bearer Tokens [RFC6750] have emerged
as popular standards for authorizing third-party applications' access
to HTTP and RESTful resources.
The conventional OAuth 2.0 interaction
involves the exchange of some representation of resource owner
authorization for an access token, which has proven to be an extremely
useful pattern in practice. However, its input and output are
somewhat too constrained as is to fully accommodate a security token
exchange framework.
Most STSes (incl. the type specified by oAuth token exchange draft) do not deal with heterogeneous tokens as your use case requires beyond, say, oAuth to SAML or vice versa. The solution to your use case is most likely going to involve a custom-coded STS. We've implemented STSes that translate oAuth/SAML to anything (e.g. SOAP with a custom credentials header like yours) for our clients using a variety of products/stacks/platforms/etc.
We often use Salesforce as the platform, it provides a lot of plumbing that helps with this use case. To be fair, similar plumbing is available in quite a few platforms and stacks - from the big 3 (AWS/GCP/Azure) to Java/Python/Ruby/Node/Go with appropriate libraries to identity & access management products such as Keycloak.