Instead of using an OpenIdConnect authentication method I instead used a JWT Bearer like so:

services.AddAuthentication(options =>
            {
                options.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
            })
 .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, opt =>
            {
                opt.Authority = "https://my.fusionauth.instance";
                opt.RequireHttpsMetadata = true;
                opt.SaveToken = true;

                opt.TokenValidationParameters = new TokenValidationParameters()
                {
                    ValidAudience = "my application id / client id";
                };
            });

I could add the oidc back and use it to so long as I decoreate my Authorize attributes with that authentication scheme.

Now the pipeline calls my fusion auth instance and checks the token matches and has not been tampered with. To get this to work I had to create my own Key in FusionAuth and apply it to the JWT settings of my application. Then when the runtime calls https://my.fusionauth.instance/.well-known/jwks.json it returns the key needed to validate the token.

Now to get roles to work ...

I'm trying to integrate FusionAuth with a .NET Web API. I can sucessfully login a user using Postman to fusionauthinstance\login passing the following:

{
    "applicationId": "my mobile app id in fusionauth",
    "loginId": "my@user.com",
    "password": "mypassword",
    "metaData":{
        "device":{
            "type": "MOBILE"
        }
    }
}

This returns authentication and refresh tokens along with user registration information.

However, when I then try to post to one of my APIs it returns the FusionAuth login page instead of authenticating based upon my token. I can see it going to the authorize endpoint with the following URL:

https://my.fusionauth.instance/oauth2/authorize?client_id=myclientid&redirect_uri=https%3A%2F%2Flocalhost%3A44342%2Fsignin-oidc&response_type=code&scope=openid%20profilecode_challenge=&code_challenge_method=S256&response_mode=form_post&nonce=&state=&x-client-SKU=ID_NETSTANDARD2_0&x-client-ver=6.8.0.0 

This is my API setup code inside my Startup.cs:

services.AddAuthentication(options =>
            {
                options.DefaultScheme = "Cookie";
                options.DefaultChallengeScheme = "oidc";
            })
            .AddOpenIdConnect("oidc", options =>
            {
                options.Authority = "https://my.fusionauth.instance";
                options.ClientId = "the application id of my API app in FusionAuth";
                options.ClientSecret = "shhhitsasecret";
                options.Scope.Add("openid");

                // leave this in, otherwise the aud claim is removed. See https://stackoverflow.com/questions/69289426/missing-aud-claim-in-asp-net-core-policy-check-prevents-authorization-but-it for more
                options.ClaimActions.Remove("aud");

                options.ResponseType = "code"; //Authorization Code Flow
                options.RequireHttpsMetadata = true; //always
                options.TokenValidationParameters = new TokenValidationParameters
                {
                    ValidateAudience = true,
                    ValidAudience = "same as clientid above" //the clientid as per openid spec
                };
            })

I'm sure I'm missing something fundamental here but I can't find it.

Thanks in advance.

Because of how IIS process header (server) variables. You need to append HTTP_ to the headers and change dashes to underscores like so:

  <set name="HTTP_X_Forwarded_Proto" value="https" />
  <set name="HTTP_X_Forwarded_Host" value="mydomain.com" />
  <set name="HTTP_X_Forwarded_Port" value="443" />

And now it works. It might be a good idea to add a page on this to the official docs too.

I just had to do this with IIS on Windows. Its quite simple and allows you to leave your Tomcat config alone, which for Windows users, is quite daunting and prone to error.

1. You will need to install the AAR for IIS: https://blogs.sap.com/2014/11/05/how-to-configure-iis-arr-application-request-routing-to-redirect-to-tomcat/
2. And then add the 443 binding to the IIS default website with your own certificate.

This means I can now use my own secure custom domain (I have a wildcard domain) with SSL.

Although, now I'm getting a Proxy Configuration error which kindly gives me instructions to fix, but I can't get it to work yet...