In addition to SAML, you can also use an OIDC enterprise connection or a custom OAuth 2.0 social connection to federate between two tenants. Given tenant B would delegate authentication to tenant A through the means of the connection type you chose this would allow a user already logged in into tenant A to complete a login through tenant B without technically having to provide credentials again as the authentication session in tenant A could be leveraged.
However, in neither of the possibilities above there would actually be a POST of an ID token from one tenant to the other, although I don’t think that would be relevant for the overall requirement as using a connection to federate the two tenants should meet the requirements.
In particular, application A_APP defined in tenant A performs a normal authentication; at this this time an authenticated session is established in tenant A.
If the user goes to B_APP defined in tenant B (which has a connection to tenant A) as part of the login page of tenant B the user would be allowed to login through that connection which would imply SSO would occur due to the previously existing session in A.
The above would allow for B_APP to get an access token for an API in tenant B on behalf of the user.
The reference documentation:
- OIDC connection - Connect to OpenID Connect Identity Provider
- OAuth 2.0 connection - Connect Apps to Generic OAuth2 Authorization Servers