OAuth2 Token Exchange vs. STS Token Exchange vs. OIDC Token Validator Node

Architecture
, , , , ,
1

I am looking for some guidance how the FR platform will evolve and therefore a good practice what route to follow.
The final goal is to propagate the identity from the client all along the way to the back end in a multi API Layer architecture, i.e. client calls API Layer 1, which calls API Layer 2, …, which calls the final API. The APIs might be in different security / trust realms (e.g. different cloud providers or different business entities in a B2B scenario), so assume a token exchange scenario with one or multiple IDPs.
I came across the following AM options for token exchange:

  • OAauth2 Token Exchange
  • OIDC Token Validator Node with OAuth2 Token Exchange
  • STS Token Exchange with OAuth2 Token Exchange

  1. OAuth2 Token Exchange
    As of AM documentation this is restricted to: “clients can only exchange tokens at the OAuth 2.0 provider that issued them”. A multiple IDP scenario with different security / trust domains is not supported. But the Spec does not limit OAuth2 token exchange to a single OAuth2 provider scenario.
    Are there concrete plans to enhance AM to support multi OAuth2 providers?

  2. OIDC Token Validator Node with OAuth2 token exchange
    In a multi IDP scenario I can use an authentication journey with an OIDC Token Validator Node. As a result of a successful validation and therefore authentication the client will receive an ID Token issued from AM. This AM issued ID Token can be exchanged at AM via OAuth2 token exchange for any access token.

  3. STS Token Exchange
    As of AM documentation STS is made for “cross-domain trust federation relationships” and STS REST service supports username/password, SSO tokens, X.509 certificates, and ID tokens as input tokens, and SAML v2.0 assertions and ID tokens as output tokens. This means I can’t exchange ID Token for access token or access token for access token. I could exchange at STS and ID Token of Trust domain 1 for an ID Token of AM and use the AM issued ID Token with OAuth2 token exchange to get an access token.

Do I miss something or what is the foreseen concept of AM and what route do you suggest to follow in a multi IDP Scenario?
I want to stay in the concept of the product and do not want to start custom development which might deviate me from the (future) concept.