Use of external authentication provider for user credentials, private IdentityServer for token generation

I am designing a security backend which is supposed to provide tokens for several clients in order to protect a number of APIs. The user database is in Azure B2C https://azure.microsoft.com/en-us/services/active-directory-b2c/. I want to create API tokens that contains different claims based on user access. E.g: User A should be able to call /api/stores/11, but not /api/stores/12.

Use cases:

• An app (iPad) that goes directly to Azure B2C for user login and token generation. Use this token to call APIs for user profile social interaction etc.
• External systems who will call the same APIs (different modules) with access rights limitations. The external systems will have administrators who will also get credentials from Azure B2C.

My solution so far:

1. IdentityServer4 (https://github.com/IdentityServer/IdentityServer4) that calls Azure B2C login to verify user credentials.
2. Once authentication is complete (on callback), the IdentityServer will apply whichever claims the user has (access rights etc) for the external systems, then generate a token. IdentityServer will have a local database that connects userid/emails with access rights.
3. APIs will use multi-tenant authentication providers to support BOTH a token from Azure B2C AND my "in-between" IdentityServer. The providers are IdentityServerAuthentication and OpenIdConnectAuthentication respectively.

My question is if this is a viable solution? Is it too complicated? What would you do differently in this case? I don't want to implement a second user login, and Azure B2C doesnt seem to support fine-grained access rights.

This is actually a very common architecture.

The core identity and token platform is owned by you - and that is the only sane thing to do.

You can then use whatever mechanism (in your case Azure B2C) to do authentication. You might want to add a local database with users or some other authentication mechanism in the future. And that's totally fine.

The important point is - your applications don't care about that. All they know is your platform (in your case built using identityserver). If you decide one day you need to change your authentication provider - that's fine. Your applications are shielded from that fact.

At this point, your apps and services only need to trust the tokens coming from identityserver - identityserver takes care of brokering the trust with the external parties.