Oidc-client-js: Is Oidc.UserManager singleton or can have multiple objects

[pottabathini]

we are trying to hook multiple policies using Oidc.UserManager by creating multiple objects by passing the different set of settings.

We are working on Azure B2C where we can create multiple policies like Sign-in, Edit Profile, Sign -in and Sign-up polices. Each policy has its own settings to make them work we are trying to create multiple objects for Oidc.UserManager.

For that, we want to know

1. Oidc.UserManager act as a singleton object or can have multiple objects.
2. If I create multiple objects for Oidc.UserManager and hook events for all the objects differently, when Oidc trying to fire addAccessTokenExpiring eventwill it will fire for all the objects events at a time or based on the expires_in time it will fire specific object event.
   Example: Object A have expires_in have 180 seconds and Object B have expires_in have 120, if clock reaches 60seconds it will fire Object B only or it will fire Object A also?

[brockallen]

1: You can create many instances of UserManager, but it stores things and the key is based on the combination of the authority and the client id. So if B2C uses the same authority and client id for its multiple endpoints, then this will be a problem. As a side note, I'm quite confused by that design -- i thought they used a custom "p" param to the one authorization endpoint to trigger the different profiles? Anyway...

2: The events and timers will be per-instance, per-user.

[brockallen]

BTW, you should check to see if B2C supports CORS on its metadata endpoint. Normal AAD does not.

[pottabathini]

hmm yes, currently B2C also not supports CORS. We put metadata manually and it is working fine.

Even we added manually metadata we kept using authority and clientid same across multiple usermanager objects, because of that it not worked for us.

Now we modified all the authorities to accept different URLs and SPA is working fine across multiple policies 👍

Can we assume if we add metadata and keys manually, authority endpoint will not be useful in this case?

[brockallen]

Can we assume if we add metadata and keys manually, authority endpoint will not be useful in this case?

Authority as a value is still needed to uniquely identify the OP/STS/IdP you're using. You will still need to set it, and it still needs to be unique for each OP you're using.

[FreeWillaert]

Regarding "_You can create many instances of UserManager, but it stores things and the key is based on the combination of the authority and the client id_":

I bumped into the same question - I want to use multiple user managers for different audiences (not with IdSrv but another authorization service).
I think it is solved by passing a userStore with a custom prefix to the UserManager constructor:

new UserManager({
    ...,
    userStore: new WebStorageStateStore({ prefix: `oidc.${userManagerName}.`, store: sessionStorage })
})

So, I have different UserManager objects, each identified by some kind of name, and using different session storage entries.

This seems to work, unless I'm overlooking something?