AllowInsecureHttp should allow onion addresses (Tor)

[NicolasDorier]

AllowInsecureHttp should allow onion addresses (Tor)

[kevinchalet]

Interesting scenario 😄

What warning are you referring to, exactly? The one logged when during app initialization?

AspNet.Security.OpenIdConnect.Server/src/AspNet.Security.OpenIdConnect.Server/OpenIdConnectServerInitializer.cs

Lines 174 to 179 in e68c362

	if (options.AllowInsecureHttp && _hostingEnvironment.IsProduction())
	{
	_logger.LogWarning("Disabling the transport security requirement is not recommended in production. " +
	"Consider setting 'OpenIdConnectServerOptions.AllowInsecureHttp' to 'false' " +
	"to prevent the OpenID Connect server middleware from serving non-HTTPS requests.");
	}

If so, this should be addressed in OpenIddict 3.0, where we'll no longer have this check.

[NicolasDorier]

cool!

Just for information, when OpenIddict 3.0 is out?
We are using openiddict for new feature, so it would be a shame if we develop on something that will soon be supersede by new version (ping @Kukks)

[kevinchalet]

The first experimental 3.0 bits should be pushed to GitHub soon (probably later this week) but they'll have many missing features, that will be progressively reintroduced over time. Once I'm sure it meets the usual security bar, I'll start pushing alpha packages on MyGet (so folks can torture it 😄).

.NET Core 3.0's GA is scheduled for September but won't be a LTS version. 3.1 - that will have long-term support - is currently scheduled for November. We should have production-ready packages available by then (at least for the core/server/validation features).

IMHO, there's no need to rush for the 3.0 bits: the core part will be identical and it shouldn't be too hard to migrate to the new server/validation packages. I took a brief look at btcpayserver and I'm confident it shouldn't be too painful: only the event handlers will have to be reworked a bit to adopt the new simplified API. Here's an example of an event handler in 3.0:

/// <summary>
/// Contains the logic responsible of rejecting authorization requests that specify an invalid response_mode parameter.
/// </summary>
public class ValidateResponseModeParameter : IOpenIddictServerHandler<ValidateAuthorizationRequestContext>
{
    /// <summary>
    /// Gets the default descriptor definition assigned to this handler.
    /// </summary>
    public static OpenIddictServerHandlerDescriptor Descriptor { get; }
        = OpenIddictServerHandlerDescriptor.CreateBuilder<ValidateAuthorizationRequestContext>()
            .UseSingletonHandler<ValidateResponseModeParameter>()
            .SetOrder(ValidateResponseTypeParameter.Descriptor.Order + 1000)
            .Build();

    /// <summary>
    /// Processes the event.
    /// </summary>
    /// <param name="context">The context associated with the event to process.</param>
    /// <returns>
    /// A <see cref="Task"/> that can be used to monitor the asynchronous operation.
    /// </returns>
    public Task HandleAsync([NotNull] ValidateAuthorizationRequestContext context)
    {
        if (context == null)
        {
            throw new ArgumentNullException(nameof(context));
        }

        // response_mode=query (explicit or not) and a response_type containing id_token
        // or token are not considered as a safe combination and MUST be rejected.
        // See http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#Security
        if (context.Request.IsQueryResponseMode() && (context.Request.HasResponseType(ResponseTypes.IdToken) ||
                                                      context.Request.HasResponseType(ResponseTypes.Token)))
        {
            context.Logger.LogError("The authorization request was rejected because the 'response_type'/'response_mode' " +
                                    "combination was invalid: {ResponseType} ; {ResponseMode}.",
                                    context.Request.ResponseType, context.Request.ResponseMode);

            context.Reject(
                error: Errors.InvalidRequest,
                description: "The specified 'response_type'/'response_mode' combination is invalid.");

            return Task.CompletedTask;
        }

        // Reject requests that specify an unsupported response_mode.
        if (!string.IsNullOrEmpty(context.Request.ResponseMode) && !context.Request.IsFormPostResponseMode() &&
                                                                   !context.Request.IsFragmentResponseMode() &&
                                                                   !context.Request.IsQueryResponseMode())
        {
            context.Logger.LogError("The authorization request was rejected because the '{ResponseMode}' " +
                                    "response mode is not supported.", context.Request.ResponseMode);

            context.Reject(
                error: Errors.InvalidRequest,
                description: "The specified 'response_mode' parameter is not supported.");

            return Task.CompletedTask;
        }

        return Task.CompletedTask;
    }
}

[NicolasDorier]

@PinpointTownes thanks for the information.

we will then continue on 2.0. I did not knew that the 3.0 was for .NET 3.0. We will move to .NET 3.0 only after the first LTS.

That said, I was expecting .NETCore2.1 packages to "just work" on .NETCore3.0. That is not the case? (assuming no netstandard support)