Only call AddDataProtection in Authentication Services that require it

[eerhardt]

In .NET 8, we have a goal to enable JWT authentication with Native AOT. See Stage 2.a in #45910.

In order to use JWT authentication, the app needs to call builder.Services.AddAuthentication(). When bringing in AddAuthentication(), we are getting trimming / NativeAOT warnings from System.Security.Cryptography.Xml. System.Security.Cryptography.Xml is not currently trimming / NativeAOT compatible. See dotnet/runtime#73432. It also appears to be a major amount of work to make it compatible, possibly with many "gotchas".

The reason System.Security.Cryptography.Xml is brought into the app is because this line:

aspnetcore/src/Security/Authentication/Core/src/AuthenticationServiceCollectionExtensions.cs

Line 24 in 9c38b37

services.AddDataProtection();

DataProtection brings in the dependency on System.Security.Cryptography.Xml.

However, to enable JWT bearer authentication, it doesn't require DataProtection. Other types of authentication services do, for example:

• Cookies
• OpenIdConnect
• OAuth
• WsFederation
• Twitter
• etc

So it made sense originally to add DataProtection in a common place, and if the app didn't use it - no big deal. But now with NativeAOT and trimming, it does affect the app because the unused code can't be trimmed from the app - making it bigger unnecessarily.

To solve both the size issue (being able to trim the unused DataProtection code) and the fact that System.Security.Cryptography.Xml is not compatible with NativeAOT/trimming, we should remove AddDataProtection() from AddAuthentication() and instead move the calls to all the specific authentication services that require it.

Note that this would be a breaking change because an app could just call AddAuthentication(), without calling one of the built-in auth services, and then try to get DataProtection services, it will fail (since they aren't registered).

Alternatives

One alternative is to create a new AddAuthenticationCore() method that doesn't call AddDataProtection(), but does everything else AddAuthentication() does today.

cc @halter73 @davidfowl @JamesNK @DamianEdwards

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[Tratcher]

Yes, this would be breaking for most 3rd party auth providers.

AddAuthenticationCore would avoid the break, but would have to be used directly in program.cs and the template.

[eerhardt]

@Tratcher - do you have an opinion on which approach we should take?

[Tratcher]

AddAuthenticationCore has discoverability issues. How about this:

public static class AuthenticationServiceCollectionExtensions
{
    public static AuthenticationBuilder AddAuthentication(this IServiceCollection services)
    public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, string defaultScheme)
    public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, Action<AuthenticationOptions> configureOptions)
+   public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, bool withDataProtection)
+   public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, bool withDataProtection, string defaultScheme)
+   public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, bool withDataProtection, Action<AuthenticationOptions> configureOptions)
}

I'd also set a bool on AuthenticationBuilder bool HasDataProtection { get; } that callers like AddOpenIdConnect would check and throw if it wasn't enabled. That way they fail at startup instead of on individual requests.

[eerhardt]

Unfortunately that proposal is not trim friendly. The trimmer is not able to see that withDataProtection is only ever passed false. See dotnet/linker#1868.

[Tratcher]

Darn. So we end up with:

public static class AuthenticationServiceCollectionExtensions
{
    public static AuthenticationBuilder AddAuthentication(this IServiceCollection services)
    public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, string defaultScheme)
    public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, Action<AuthenticationOptions> configureOptions)
+   public static AuthenticationBuilder AddAuthenticationCore(this IServiceCollection services)
+   public static AuthenticationBuilder AddAuthenticationCore(this IServiceCollection services, string defaultScheme)
+   public static AuthenticationBuilder AddAuthenticationCore(this IServiceCollection services, Action<AuthenticationOptions> configureOptions)
}

I'd still want that bool on AuthenticationBuilder bool HasDataProtection { get; } that callers like AddOpenIdConnect would check and throw if it wasn't enabled.

[eerhardt]

that callers like AddOpenIdConnect would check and throw if it wasn't enabled.

Why wouldn't AddOpenIdConnect just call AddDataProtection() if it needs it? Why would it require someone else to do it?

[Tratcher]

Good point 😆.

[davidfowl]

Unfortunately that proposal is not trim friendly. The trimmer is not able to see that withDataProtection is only ever passed false. See dotnet/linker#1868.

• It tightly couples the method to the implementation
• It doesn’t scale well for other things we may want to exclude

[eerhardt]

I just remembered there already is an AddAuthenticationCore method:

aspnetcore/src/Http/Authentication.Core/src/AuthenticationCoreServiceCollectionExtensions.cs

Line 19 in 3265dc6

public static IServiceCollection AddAuthenticationCore(this IServiceCollection services)

The issue with it and JwtBearer authentication is that JwtBearer also needs an ‘IAuthenticationConfigurationProvider’, which is only added by AddAuthentication.

So other options would be:

• move the default IAuthenticationConfigurationProvider service registration from AddAuthentication to AddAuthenticationCore.
• Have AddJwtBearer add the default IAuthenticationConfigurationProvider service if it hasn’t already been registered.