Identity Server - multiple STS - microservices

Question

I have two groups of api applications (group 1: api11, api12; group 2: api21, api22) that are used by two different groups od javascript applications (group 1 and group 2). Each api group has different domain and use different instance of Identity Server (also each identity server has different domain). Business requirement is that user logged in to any application from group 1 can use any app from this group but can't use app or api from group 2.
Under the hood both api1 and api2 often needs to talk to the same microservices. What I want to achive is to make microservices accessible with access tokens issued from any of the identity servers (used by group 1 or group 2 app). Is there any way to achieve this? For one identity server I can use UseIdentityServerBearerTokenAuthentication but as argument I can pass only one Authority there.

Answer 1

It is not directly possible (see this issue)
But you probably need to rethink your architecture. Assuming the business requirement (Business requirement is that user logged in to any application from group 1 can use any app from this group but can't use app or api from group 2.) is non negotiable, what you are trying to achieve may be dangerous if these microservices are handling something very particular to one or the other group (ie, I am talking about multitenancy here)
The right approach in your case would be to have separate instances of microservices, dedicated to different groups, ideally running in their own containers or VMs

Answer 2

So I think this should be possible although whether you really want to do it or not is another question! I haven't tried this but you'd need to do something along the lines of:
Use the same signing certificate from both IdentityServers
To validate your JWTs, use the Microsoft extension "UseJwtBearerAuthentication" instead of using the IdentityServer validator (which is set with the UseIdentityServerAuthentication extension not UseIdentityServerBearerTokenAuthentication - the latter is IdentityServer3 I think). IdentityServer uses the Microsoft validator under the hood anyway, code and docs:
Our authentication middleware serves the same purpose as the above middleware (in fact it uses the Microsoft JWT middleware internally)
The reason for using the Microsoft validator directly is that now you can avoid setting the authority when you set it up, this would normally be used to validate the "iss" (issuer) as part of validating the JWT. Instead you can configure multiple valid issuers (i.e. your two IdentityServers) and point the validator directly at the signing cert that you are using in step 1:
var tokenValidationParameters = new TokenValidationParameters
{
ValidateIssuerSigningKey = true,
ValidateIssuer = true,
ValidIssuers = new[]
{
"http://my_first_IdentityServer/",
"http://my_second_IdentityServer/"
},
IssuerSigningKey = new X509SecurityKey(new X509Certificate2(certLocation))
};
app.UseJwtBearerAuthentication(new JwtBearerOptions()
{
Audience = "http://localhost:5001/",
AutomaticAuthenticate = true,
TokenValidationParameters = tokenValidationParameters
});
The above is adapted from the article here. As it says in the article, you could equally (and preferably) use a certificate store rather than a cert file.
Btw, we're obviously talking authentication here, how you authorise users across the APIs will no doubt add extra complexity.