Consider a use-case in which a single page application using an OAuth identity flow has to use one of many possible identity providers, as determined by what user is logged in. More specifically, I log in using my credentials for Company A, and the app directs the client app to use Okta, and if I log out and log in again using different credentials for a different company, Google is used as the auth provider (the provider is associated to a specific company/user by info stored server-side).
The client-side app would be mostly agnostic to which auth provider is being used as long as it has a token to hit the main app's backend API. What it would need to know though is what URL to hit to initially log in, and where to occasionally obtain a refreshed token (where it would also pass an HTTP-only session cookie that was issued on log in).
The only thing I can think of is that the log in step also sets another JS-accessible cookie, or uses localstorage, that simply stores the provider name and/or refresh endpoint. I don't know if there is anything particularly insecure about this approach, but I thought I'd see if anyone had any better ideas on how to handle this use case?