Redirect URI is always HTTP - but only in production

[simone.saviolo_auth0]

Hello everyone. First-time Auth0 user here, implementing it in a .Net 6 regular web app. Everything is fine until I deploy my app to Heroku: what happens there is that, when logging in, the redirect URI gets changed to HTTP. At first I managed to hack it by adding the HTTP URI in the allowed callback URIs (which was of course bad), but now an issue surfaced where the correlation cookie, which is marked as Secure, gets stripped in the resulting HTTP request.

My application lives at this URL: the home page is public, but if you try to enter any other page (for example the “Events” link at the top) you need to authenticate. It seems like the Authorize attribute is redirecting to http://sr4fun-results.herokuapp.com/account/login, instead of https://.... However, if I visit the HTTPS version of that URL (https://sr4fun-results.herokuapp.com/Account/Login?ReturnUrl=%2Fevents), I still get redirected to Auth0 with an HTTP URL as the redirect URI.

I don’t know which part of my setup is involved in transforming the URL scheme, as none specifies it directly. Here is my code:

Program.cs

// unrelated dependency injection and configuration

builder.Services.ConfigureApplicationCookie(options => 
{
    options.LoginPath = "/account/login";
    options.LogoutPath = "/account/logout";
});
builder.Services.Configure<Auth0Configuration>(builder.Configuration.GetSection("Auth0"));
builder.Services.AddAuth0WebAppAuthentication(options =>
{
	Auth0Configuration auth0Configuration = builder.Configuration.GetSection("Auth0").Get<Auth0Configuration>();
    options.CallbackPath = "/callback";
	options.Domain = auth0Configuration.Domain;
	options.ClientId = auth0Configuration.ClientID;
    options.ClientSecret = auth0Configuration.ClientSecret;
    //options.ResponseType = "code";
});

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
	app.UseExceptionHandler("/Home/Error");
	// The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
	app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseCookiePolicy();
//app.UseSession();

app.UseRouting();

app.UseAuthentication();
app.UseAuthorization();

app.UseStatusCodePagesWithReExecute("/error/{0}");

app.MapControllerRoute(
	name: "default",
	pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run();

What am I doing wrong?

[nelson1]

Hi,

We have the same issue.
When the application redirect to the login actin, the scheme is set to HTTP and not https.

everything works correctly on localhost but once deployed on our cloud (AWS beanstalk), the redirectURI is always set to HTTP instead of HTTPS.

@simone.saviolo_auth0 did you find a solution to solve this?
If yes, could you share it

[simone.saviolo_auth0]

More of a workaround than a proper solution, but this is what I’ve been using to explicitly set the redirect URI:

builder.Services.AddAuth0WebAppAuthentication(options =>
{
	// Other configuration
	options.LoginParameters = new Dictionary<string, string>()
	{
		{ "redirect_uri", $"{auth0Configuration.BaseSiteURL}/callback" },
	};
});

I investigated the issue a bit more on Github, but got no solution.

[phil.cole]

We have had this issue elsewhere previously in our code running in Kubernetes , and now here. I suspect the issues above in Heroku and beanstalk are caused by the same thing.

This is related to how ASP.NET Core builds absolute URLs based on the incoming request - details here, summarised nicely in the first comment of the accepted answer.

Basically if you are running in Kubernetes, your browser will make a request over https to the domain name. Kubernetes/nginx will intercept this request and pass it on to your actual app, but using http. At the same time, it should add a header “X-Forwarded-Proto” set to https, so you know what the original protocol was.

When ASP.NET Core builds the redirect_uri, it will use the same protocol as its direct request, that is http. It doesn’t check for this X-Forwarded-Proto or anything else.

The best way to get around this is by adding the ForwardedHeaders Middleware and applying the XForwardedProto header:

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedProto;
});


var app = builder.Build();
app.UseForwardedHeaders(); // note this should be added as early as possible

We found this caused problems with another specific part of our code, so another possible option is to manipulate the redirect_uri in the OIDC event before it is sent to Auth0, similar to suggested in this post.