Identity Server 4 Custom Scheme

Question

I'm currently working on setting up Identity Server 4 as a centralized authn point for multiple products as well as a federation gateway. It's all pretty standard:

I have users that can authenticate into an SPA that uses the OIDC-Client js lib to interact with my identity server using the implicit flow. User stores are as follows:

• a user store local to IDSRV (Asp.net identity). They'd enter their credentials into a form hosted in IDSRV, just as seen in the docs
• an openid connect or oauth 2 store, either a social (google, linkedin, etc) integration or an IDP provided by one of our clients. Also working, just like in the docs.
• a "destination key", described below

Destination key - the application in question has the ability to generate a unique link with a key (pretend it's a guid, for example purposes). This key maps to a specific destination in the app, and serves as a defacto authentication. It's a lot like the resource owner password flow, except that the key is the sole component needed to authenticate. (I'm aware that this isn't the utmost in security, but it's a business decision, taking into account the lower levels of protection).

Which brings me to my question: what is the proper "identity server" way of accomplishing this destination key authentication mechanism. Some things I've considered:

• a custom authentication scheme configured in IDSRV. I added a generic scheme called "destkey", with accompanying AuthenticationHandler and AuthenticationSchemeOptions implementations. The HandleAuthenticateAsync method would use an injected service to validate the destination key. For some reason, it ignores this and continues to validate against Asp.Net identity
• a custom grant type. I looked to create an implementation of IExtensionGrantValidator that would utilize the destination key service to validate the key. I haven't been able to get this working, at least in part because the OIDC lib doesn't allow the configuration of a grant type.
• repurposing the "Login" method of the AccountController from the IDSRV Quickstart [HttpGet] public async Task<IActionResult> Login(string returnUrl) This would basically strip the destination key off the URL and call HttpContext.SignInAsync using the dest key as the subject. This isn't working, as it seems to check the database for the existence of the subject (which is how I ended up attempting to create a custom scheme as described above)

Any thoughts on the proper extensibility point to accomplish this would be most welcome...

Answer 1

Not sure if this is the best approach, but I ended up creating a custom implementation of IProfileService. It wraps an instance of IdentityServer4.AspNetIdentity.ProfileService, and checks for the existence of a "destination_key" claim. If the dest claim exists, it references the destination key service for validation - otherwise, it delegates the logic to the underlying ProfileService instance, which uses Asp.net identity.

In the Login method of the AccountController, I simply check the acr_values for a destination key passed from the client. This is set in the signinRedirect method of the OIDC-Client.js lib.