signin-oidc redirect not working OpenId Connect

Question

I am having an issue when redirecting to signin-oidc after the consent page. Locally I have no issues I can Login -> Consent -> signin-oidc -> redirected to landing page no problem with all cookies updated properly.

However, when the server is deployed in AWS Fargate it does not work. I am not sure if this is middleware related or IS4 related, but I can connect to the test IS4 server https://demo.identityserver.io/ without issue.

I am using the same Config and TestUsers with InMemory settings from https://github.com/IdentityServer/IdentityServer4.Demo.

Here is the startup on my IS4 server:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<IdentityContext>(options => options.UseNpgsql(Configuration.GetConnectionString("IdentityContext")));
    services.AddDbContext<MultitenancyContext>(options => options.UseNpgsql(Configuration.GetConnectionString("MultitenancyContext")));

    // Add identity services to handle user login
    services.AddIdentity<ApplicationUser, IdentityRole>()
        .AddEntityFrameworkStores<IdentityContext>()
        .AddDefaultTokenProviders();

    if (!HostingEnvironment.IsDevelopment())
    {
        services.AddSingleton<IAmazonS3>(new AmazonS3Client(RegionEndpoint.USEast1));
        services.AddSingleton<IAmazonKeyManagementService>(new AmazonKeyManagementServiceClient(RegionEndpoint.USEast1));
        services.AddDataProtection()
            .SetApplicationName("accunet-web")
            .ProtectKeysWithAwsKms(Configuration.GetSection("DataProtectionKms"))
            .PersistKeysToAwsS3(Configuration.GetSection("DataProtectionS3"));
    }

    services.AddOptions();

    services.AddMvc();

    services.AddTransient<IUnitOfWork, UnitOfWork>();

    services.AddIdentityServer(options =>
    {
        options.Events.RaiseErrorEvents = true;
        options.Events.RaiseFailureEvents = true;
        options.Events.RaiseInformationEvents = true;
        options.Events.RaiseSuccessEvents = true;
    })
        .AddInMemoryApiResources(Config.GetApis())
        .AddInMemoryIdentityResources(Config.GetIdentityResources())
        .AddInMemoryClients(Config.GetClients())
        .AddTestUsers(TestUsers.Users)
        .AddDeveloperSigningCredential(persistKey: false);
}

And the startup from my test client website, which I have deployed to Azure along with localhost testing:

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<CookiePolicyOptions>(options =>
    {
        // This lambda determines whether user consent for non-essential cookies is needed for a given request.
        options.CheckConsentNeeded = context => true;
        options.MinimumSameSitePolicy = SameSiteMode.None;
    });

    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(
            Configuration.GetConnectionString("DefaultConnection")));
    services.AddDefaultIdentity<IdentityUser>()
        .AddDefaultUI(UIFramework.Bootstrap4)
        .AddEntityFrameworkStores<ApplicationDbContext>();

    services.AddAuthentication(options =>
        {
            options.DefaultScheme = "Cookie";
            options.DefaultChallengeScheme = "challenge";
        })
        .AddCookie("Cookie")
        .AddOpenIdConnect("challenge", options =>
        {
            options.Authority = "http://auth.is4server.com";
            options.SignInScheme = "Cookie";
            options.RequireHttpsMetadata = false;
            options.ClientId = "server.hybrid";
            options.ClientSecret = "secret";
            options.ResponseType = "code id_token";
            options.SaveTokens = true;
            options.GetClaimsFromUserInfoEndpoint = true;
            options.Scope.Add("offline_access");
            options.Scope.Add("profile");
            options.Scope.Add("openid");
        });

    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
}

These two systems work fine locally, but when deployed I get the error:

System.Exception: An error was encountered while handling the remote login. ---> Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectProtocolException: Message contains error: 'invalid_request', error_description: 'error_description is null', error_uri: 'error_uri is null'.
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.RedeemAuthorizationCodeAsync(OpenIdConnectMessage tokenEndpointRequest)
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.HandleRemoteAuthenticateAsync()
   --- End of inner exception stack trace ---
   at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler`1.HandleRequestAsync()
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.MigrationsEndPointMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

The only difference I can see is locally it is redirecting to signin-oidc with Type : x-www-form-urlencoded, which works properly.

But on the depolyed IS4 server it redirects with Type : document and gets a 500 error. But the headers still have all of the information I need, but signin-oidc does not accept the form and fails.

I am looking into having my own signin-oidc endpoint instead of using the middleware but I want this to be easily adaptable for my clients to use my IS4 server.

Any help would be much appreciated as I have been struggling with this for a couple days.

Here is the content of the failed signin-oidc content:

General

Request URL: http://localhost:5002/signin-oidc
Request Method: POST
Status Code: 500 Internal Server Error
Remote Address: [::1]:5002
Referrer Policy: no-referrer

Response Headers

Content-Type: text/html; charset=utf-8
Date: Wed, 13 Mar 2019 17:59:10 GMT
Server: Kestrel
Transfer-Encoding: chunked

Request Headers

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 1477
Content-Type: application/x-www-form-urlencoded
Cookie: .AspNetCore.OpenIdConnect.Nonce.CfDJ8G7d4NhrgFZAqO8IaG32oQ1zWDYRXeddV8UbbHzWM9_aj1-yBLqDHuKbrfGsEUiG3nPgOUL3zL4of6OK6dse4JkeFEhtK1Av1gwgduIWeT64sBQf3M0infYZFz2zLdZs3trHWd1RYH0vMAl697Q5qQqJYaOAfSELnddZOfhdPxqKJprpDil9o-RqQh5RyWU33IwXilBe1vRKvepkeIxgphoiLYtS_-YjPwCQXB_sBRIuB44FobwUWxFLJKDxA4xYHQlOW8smYTjo0hIZrsZnx0w=N; .AspNetCore.Correlation.challenge.Kia1WjnjAxluHmIXm3J5lO1TOWbzLXjidVC3fXfDmBk=N
Host: localhost:5002
Origin: null
Pragma: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36

Form Data

code: bebbb3b72584a8270a574804b685e908848cd30b038748e246704a1f7195d8af
id_token: eyJhbGciOiJSUzI1NiIsImtpZCI6IjI4Y2NmMWYwNDY5MmVmZGQ5Y2NmOTFjMjg5ZDQxNjZlIiwidHlwIjoiSldUIn0.eyJuYmYiOjE1NTI1MDAwMjcsImV4cCI6MTU1MjUwMDMyNywiaXNzIjoiaHR0cDovL2F1dGguYXNjLWFjY3VuZXQtZGV2LmNvbSIsImF1ZCI6InNlcnZlci5oeWJyaWQiLCJub25jZSI6IjYzNjg4MDk2NzQ3OTUxNDE5OC5ZekV5TkdWa016RXRPVFE0WlMwME9EUXdMVGxtTVRFdFpEWmpZV1JtTkdGak0yUmhZakkyWTJVNVlqRXRNakF5TUMwME1UWTBMVGd5TjJVdFl6WmtPVFZpTkRGa056azQiLCJpYXQiOjE1NTI1MDAwMjcsImNfaGFzaCI6ImI2UEJ2YVcxa0FCOThBODBpcUFnRWciLCJzaWQiOiI0NDE4NmEwNjM2YmExNzRkNzNiMmM3MjE0NmMwZmMyNCIsInN1YiI6IjExIiwiYXV0aF90aW1lIjoxNTUyNDk3NDQzLCJpZHAiOiJsb2NhbCIsImFtciI6WyJwd2QiXX0.CEwEzplnC6GvwLF72yHrAdzrFqHqoq7NPiBffRTf6srS9hxcSbECDlCHaPekyfv9LaJnpZDarEeD0qjFFs60W_qELJ81qCB05QRHQndjNDu4YZNrWWNNgK6mwceLxYINNWRcqOdW-DAsI3pbmjqqzxKnsazbYZIShPYas40jtLrDvAS43xiVyJZWqBPphNR0NClILnJ0wo34oxVYqvSjSufAioDcP__U8TH1zL8Ez2nKRfS0qj6teb7OQc0qNVEiLJL8sbM6eO1ln-ulPI2HzFT_Xzkm4yHQ-V6GUjAi3HCCkOxUupX1LaXvkwj5M-vylqVwGfc_b4JPPPfjT3CUsA
scope: openid profile offline_access
state: CfDJ8G7d4NhrgFZAqO8IaG32oQ35X6s219phcUFCU9tTimiQIQMM5oEBUb9ijqcalKyYW4lqefyLTRS4PbTEntIbW9xcxTFg3dKW207iiuKRmHt9ISy_zz8O-6s0WL8bzuBaR7_-OLg7GWwHjFOa_Zhfx2rgxRSkGKkKqnazO55bbD5P__uXVkVq0PzAAeoeMznrfVb5kWBesgBfMMcbpXB7Po2A3R3bGbNvWh8wyn11WwgfCiFjl0TKUhGFK42roCf_tgebjSSmqyi3cO5a8BpXgNJ1fFFxayBA-IEYygfshrgDgoku29N8ObdqhL9rFaclOQ
session_state: NKnJ4GLxoBOycoDpZKwW6IJbND8udT6kmYbcrEI_r84.9efa5be47c4261b4abc22ff4d54d0d6a

Answer 1

The issue was related to the Load Balancer in AWS. Since I use a secure public domain for the LB it uses HTTPS but internally it uses HTTP. This redirect was causing the discovery document to have the HTTP.

Setting the PublicOrigin to the HTTPS address prevented the redirect and solve the issue.