How to set redirect_uri protocol to HTTPS in Azure Web Apps

Question

I am facing the following problem. I have an ASP Net Core 2 web app that I want to deploy to Azure. The app authentication is integrated with the Azure Active Directory, so when I try to login the following requests happen:

GET https://login.microsoftonline.com/ecf3f643-27e5-4aa7-9d56-fd350e1e9c37/oauth2/authorize?client_id=20a2bcb5-0433-4bb4-bba3-d7dc4c533e85&redirect_uri=http://myapplication.mydomain.com/account/signin [...]  200 OK
POST http://myapplication.mydomain.com/account/signin 301 Redirect --> https://myapplication.mydomain.com/account/signin
GET https://myapplication.mydomain.com/account/signin 500 Internal Server Error

The first GET is the normal Azure Active Directory login request. Notice the redirect_uri parameter has protocol http.

The second request is the redirection to the redirect_uri, a POST with some parameters. Since I have configured Azure to allow only HTTPS traffic, then IIS redirects to the same URL with HTTPS. That's the third request. Notice this third request is a GET request, since HTTP redirection is always a GET request all the paremeters of the POST request are lost, and the authentication fails giving a HTTP 500 error in the backend.

I have tried to manually change the protocol in the redirect_uri parameter manually to HTTPS, and it works as expected. So, the only thing I need is to make ASP Net Core aware that the protocol is HTTPS.

How can that be done? I've searched tons of pages in the Internet without a clear answer.

Note: the redirect_uri is set by Kestrel. Since Azure App Service puts an IIS in front of my Kestrel and does the SSL termination there, Kestrel and my app do not know the protocol is HTTPS, and therefore use HTTP in the redirect uri.

UPDATE 1

Following the advice of @Bruce I've tried the example here, cloning the repository and configuring the application and the AD as stated there, and I am able to reproduce the error.

The redirect URI continues to be with http protocol. If I only add in the AD app configuration the https endpoint as reply URL, I get the error The reply address 'http://testloginad.azurewebsites.net/signin-oidc' does not match the reply addresses configured for the application. If I add the http protocol endpoint as reply URL, then I get an HTTP 500 error like the following:

System.Exception: Correlation failed.
   at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler`1.<HandleRequestAsync>d__12.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.<Invoke>d__6.MoveNext()

I am still thinking the problem is related to Kestrel not knowing the connection is being done through HTTPS, but I do not know how to convey that information to it.

UPDATE 2

The configuration of the Azure web app I used:

• Wep App Type: Linux
• Application Settings:
  • Stack: .NET Core 2.0
  • Startup file: dotnet ./WebApp-OpenIDConnect-DotNet.dll
  • WEBSITE_HTTPLOGGING_RETENTION_DAYS: 5
  • ASPNETCORE_ENVIRONMENT: Development
  • Always ON: On
  • ARR Affinity: On
• Custom domains:
  • HTTPS Only: On
• Diagnostic logs:
  • Docker Container Logging: File System
  • Quota (MB): 35
  • Retention Period (Days): 5

In the web.config file I modified the following line to read like this:

<aspNetCore processPath="dotnet" arguments="./WebApp-OpenIDConnect-DotNet.dll" stdoutLogEnabled="false" stdoutLogFile="./stdout.log" />

Basically I put forward slashes instead of back slashes to avoid problems with Linux paths.

Everything else is configured using default settings.

UPDATE 3 As requested by @Tratcher, I add here the headers of the server reponses (for the sake of brevity I include only the headers I consider relevant, if you want to see any other one, feel free to ask me to add it):

• First request (GET https://login.microsoftonline.com/ecf...):
  • Server: Microsoft-IIS/10.0
  • Set-Cookie: ESTSAUTHPERSISTENT=AQAFCCEADDB…sts; path=/; secure; HttpOnly
  • Strict-Transport-Security: max-age=31536000; includeSubDomains
• Second request (POST http://testloginad.azurewebsites.net/signin-oidc):
  • Location: https://testloginad.azurewebsites.net/signin-oidc
  • Server: Microsoft-IIS/10.0
• Third request (GET https://testloginad.azurewebsites.net/signin-oidc):
  • Server: Kestrel

No x-forwarded-proto header appears in any of the requests.

Note that one the root of the problem may be in the redirect of the second request, that is redirecting the HTTP POST to an HTTPS GET. That redirect should not happen since the POST should have been requested through HTTPS in the first place, but that did not happen because of the wrong http protocol in the redirect_uri of the first request.

UPDATE 4

I have confirmed this issue only happens if the chosen service plan is a Linux one. The issue does not happen at all if the service plan is a Windows one (using exactly the same code and configuration from the example of UPDATE 1). This may be a workaround, but not a solution, to the problem. The Linux app service seem to be flawed.

Answer 1

I had the problem myself. I took a deep dive into Microsoft's Microsoft.AspNetCore.Authentication and found out how they constructed the redirect url:

protected string BuildRedirectUri(string targetPath)
        => Request.Scheme + "://" + Request.Host + OriginalPathBase + targetPath;

Because the Web App already forces HTTPS this can be solved with the following code in the Startup.cs

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
      ForwardedHeaders = ForwardedHeaders.XForwardedProto
});

You only have to add this reference:

using Microsoft.AspNetCore.HttpOverrides;

Answer 2

By consulting these links:

• This question ;-)
• https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?tabs=aspnetcore2x&view=aspnetcore-2.2#configure-a-reverse-proxy-server
• https://github.com/aspnet/Security/issues/1901

And applying 3 changes to the configuration, I got everything working on a Linux App Plan.

Step 1 : configure the ForwardedHeadersOptions

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.RequireHeaderSymmetry = false;
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;

    // TODO : it's a bit unsafe to allow all Networks and Proxies...
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

Step 2 : UseForwardedHeaders in the public void Configure(IApplicationBuilder app, IHostingEnvironment env) method

app.UseForwardedHeaders();

Step 3 : Only use UseHttpsRedirection for production

if (env.IsDevelopment())
{
    app.UseDeveloperExceptionPage();

    // Forward http to https (only needed for local development because the Azure Linux App Service already enforces https)
    app.UseHttpsRedirection();
}
else
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}