We have a JS single page application in an enterprise windows network that queries multiple webservices (not endpoints) in different windows subdomains and summarizes the results, so the enduser doesn't have to compile these manually. We previously used kerberos with domain trusts (which already was annoying) but recently the first service switched to OAuth... which worked fine after some starting troubles. Only one of these services is developed by my team, the others are from different parts of the company and are not created for us, we are just allowed to use them.
Now the second service is going to make the switch and has it's own clientID with different grants and we are not sure how to handle getting multiple tokens without doing one redirect per service to our ADFS.
We can't call the other services from our backend via an "On-Behalf-Of" flow because only the client is running somewhere where all services are available.
Afaik for Single Page Applications you should only use the authorization grant workflow preferable with PKCE, so we are probably kinda limited.
How does someone handle this kind of situation? I think it should be kinda common with microservices, but I didn't find best practices for that. Do we need an api gateway in our client subnet with an OBO flow if we don't want a redirect odyssey or can the client handle that in a user-friendy way?
STANDARD FLOWS
The standards based option is for each organization to design end-to-end flows like this, to provide secure access to their own data.
The client runs a single code flow at the authorization server. The client then gets an access token that can call multiple deployed APIs (aka web services):
If you have an orders API and a products API, then each API can use different required scopes. On every request each API validates the access token and checks for a required scope.
The end result is a single redirect for the end user. Meanwhile your APIs have what they need to authorize correctly, since you control details of tokens issued. To visualize all of this, see my OAuth SPA and API Workflow blog post.
TOKEN ISSUING DESIGN
The above works efficiently because clients and APIs only use tokens issued by their organization's authorization server.
The type of problem you are experiencing is common when clients try to use foreign access tokens. For example, Sign in with Google doesn't give you a suitable access token for use in your own APIs.
YOUR QUESTION
It is not clear why your SPA should need to do one redirect per service to your ADFS authorization server. Could you expand on how that works and say what scopes are involved? Why do APIs require the SPA to use a particular client ID?
What are the token requirements of each API? Do they all use tokens issued by ADFS? Do some APIs issue their own tokens? Are some APIs considered external and use tokens from an external authorization server?
It sounds like some non standard behaviour is going on, and your issue is probably unsolvable unless the API logic changes. However, if you can update your question I will provide a better answer.