[Identity] Support generating user tokens outside of web applications

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.

https://asp.net

MIT License

35.33k stars 9.97k forks source link

[Identity] Support generating user tokens outside of web applications #57947

Closed danports closed 3 weeks ago

danports commented 3 weeks ago

Is there an existing issue for this?

[X] 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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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.