Adding additional token provider to identity service from module

[Dnawrkshp]

Hi I'm trying to add a passwordless authentication to my company's Oqtane module. I'm following a tutorial here that creates a token provider and adds it to an identity service.

public class Startup  
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddIdentity<IdentityUser, IdentityRole>()
            .AddEntityFrameworkStores<IdentityDbContext>() 
            .AddDefaultTokenProviders()
            .AddPasswordlessLoginTotpTokenProvider(); // Add the custom token provider
    }
}

Since we're developing a module we don't have the ability to modify Oqtane's startup. Implementing IServerStartup and adding another identity service seems incorrect. If I were able to modify Oqtane's startup.cs, I could just add to the end of the chain like so:

// From oqtane.framework Startup.cs
services.AddIdentityCore<IdentityUser>(options => { })
  .AddEntityFrameworkStores<TenantDBContext>()
  .AddSignInManager()
  .AddDefaultTokenProviders()
  .AddPasswordlessLoginTotpTokenProvider();

Is there any way for me to accomplish something like this within a module?

Thanks!

[hishamco]

The simplest approach is to replace the registered services

[hishamco]

@sbwalker IMHO we need to make such services easy to extend and replaceable instead of replacing DI services. In the above scenario we could introduce ITokenProvider which have the default implement, but whenever need a custom implementation say PasswordlessTokenProvider just registering the new implementation in DI is enough to let Oqtane take care about the rest. I can provide a PR if this make sense

[sbwalker]

I have another suggestion... rather than introduce more interfaces ( which will impose a performance hit on startup ) why not modify the core framework to use the existing IServerStartup interface to dynamically register services which can be replaced? This is the whole purpose of IServerStartup and if we expect modules to use it then it makes sense that the core framework should use it as well ( as this provides a functional implementation ). Basically we would create a number of granular implementations of the IServerStartup interface for various services that are currently hardcoded in main Startup class, and include feature flags to enable/disable them. Then if a third party developer wanted to register their own Identity service configuration they could implement IServerStartup and disable the default Identity service registration.

[hishamco]

@sbwalker I started on a proof of concept of what you are suggested, the only issue I faces is the order of the registered coz you knew very well that the order is Startup is very important, that's why I suggested to create an interface per core service with that developers can extend those by implementing them, and the system only knows how to inject them at the right place

I will push a draft PR soon ...

[hishamco]

The PR #952 is created

[hishamco]

Seems prioritizing startup interfaces introduces a breaking change, so I think differently and I come up with another approach that I need to test before I share it with you ;)

[sbwalker]

@hishamco I am currently documenting the pros/cons of different approaches and will create a new Discussion thread. You will be able to add a description of your ideas as well.

[sbwalker]

Moving discussion to #956 as this is not specific to authentication and touches on a more general problem related to Startup Extensibility.