I would think this through end to end, in terms of identifying users in backend requests. I assume here that you have an OAuth based setup.
- Clients interact with an authorization server and are issued tokens
- The authorization server stores an account record for each user
- Clients call APIs with access tokens that contain a subject claim
- APIs identify users in business terms, to grant access to business resources
Usually both clients and APIs trust a single authorization server. This means APIs receive a single type of access token. They then map the subject claim to business resources. An example is provided in my user data management blog post.
MULTIPLE AUTHORIZATION SERVERS
Only one ADFS should provide the authorization server (AS) role. It is possible that you have this type of setup, which may be fine, eg if the components are from independent organizations:
- Client 1 / API 1 trusts AS 1
- Client 2 / API 2 trusts AS 2
But if you need to integrate users, clients and APIs together within the same organization, this setup is not recommended, since the user data management would become more complex than it needs to.
The authorization server, eg ADFS_0, can integrate with another identity system, eg ADFS_1, that has an identity provider role. In this case though, access tokens are always issued to clients by ADFS_0.
So from a client and API viewpoint there is no multi-trust. Instead they interact with their authorization server, which is their central point of trust. Within an organizational boundary, aim for a future setup where clients and APIs use the same authorization server.