[Identity] Support generating user tokens outside of web applications

[danports]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I am trying to generate password reset tokens from a console application, but that isn't currently possible because AddDefaultTokenProviders and related machinery like DataProtectorTokenProvider isn't available in a NuGet package, only in the ASP.NET app framework.

Describe the solution you'd like

I'd like AddDefaultTokenProviders to work with AddIdentityCore, e.g.

services.AddIdentityCore<MyUser>()
    .AddEntityFrameworkStores<MyDbContext>()
    .AddDefaultTokenProviders();

Additional context

There are already NuGet packages for the data protection APIs - I believe it's just the token machinery that can't be accessed from a NuGet package.

[martincostello]

You should still be able to use a
FrameworkReference from a console app to access the APIs you want to use, provided they are public and don't depend on things like HttpContext:

<ItemGroup>
  <FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>

[danports]

Thanks @martincostello, I'll explore that option a bit more. What's the rationale for what is published to NuGet as a separate package and what is not?

[martincostello]

I'm not aware of the specific reasoning for which is in which camp, but there was a big rationalisation between 2.2 and 3.0 which introduced the shared framework.

I imagine the general principle was the distinction between "stuff you need to run a typical web app" (e.g. middleware, static files) and "stuff some web apps use and is opt in" (JWT auth, Identity).

[danports]

Got it. I think the issue with FrameworkReference is that when framework-dependent assemblies are published and run in a container based on the dotnet/runtime image, they fail because the framework isn't available in the container. Rebasing the whole container image to dotnet/aspnet just to use a few token APIs seems a little excessive to me.

[MackinnonBuck]

Thanks for contacting us. This ask is not aligned with our vision and we have no plans to implement this ask. Of course, you're always welcome to fork this codebase and build off of it!

You can learn more about our triage process and how we handle issues by reading our Triage Process writeup.

See also: https://learn.microsoft.com/dotnet/standard/security/encrypting-data