Yes, OktaAuthService logs in to single server only, defined by ISSUER. And yes, I can create 2 instances of OktaAuthService, each with own ISSUER and actually that normally logs in to both server. Though, that requires me to popup window for 2nd login, otherwise its redirect replaces SPA. So, once logged in by 1st instance from SPA, I launch 2nd window and logging to 2nd OktaAuthServer, here I retrieve tokens and push them to parent window via Window.PostMessage(), after that this window closes.
Its minor inconvenience to experience 2nd window flip, though admin can live with it.
While working on this solution, I found couple interesting things in OktaAuthService component:
Both / all instances of this component use same browser’s LocalStorage key (‘okta-token-storage’) to store just received tokens.
So, last logged in instance - replaces access/id tokens in this storage, which breaks work of 1st instance. I workarounded that by storing tokens of 1st instance in app’s global var once it has logged in.
Do you consider this as a bug?
It can be easily fixed by appending okta-token-storage by unique ID of the instance.
Out-of-topic question - likely a topic for new ticket.
Does OktaAuthService support automatic token refresh? They expire, and there is no any method to refresh them. I also, did not find how to implement token refresh via Okta APIs for SPA app / PKCE.