OpenIdApplicationManager is using http redirect_uri instead of the provided https address for the app

[MikeAlhayek]

I am having an issue where the OpenID Server is seeing the redirect_uri as http NOT as https which is what I have in the settings of the application.

Current Application Settings (OpenID Server App)

I added a new application by navigating to Security >> OpenID Connect >> Management >> Applications

In the "Redirect Uris" input I provided https://subdomain.domain-example.com/signin-oidc which starts with HTTPS as you can see below

Current Client Settings (OpenID Client App)

From a completely different OrchardCore app "hosted in Azure", I enabled the OpenID Client feature and configured it to connect to the openId server. I navigated to Security >> OpenID Connect >> Authentication client

During login, I click on My OpenId Server Name provide button to login using the OpenIdServer. This redirects me to the server as expecting. However, the OpenId Server app displays the following error

invalid_request The specified 'redirect_uri' is not valid for this client application.

When I check the OpenID Server app logs I can see that the return_uri is indeed invalid. Here is a dump of what I see in the logs

OpenIddict.Server.OpenIddictServerDispatcher|INFO|The request URI matched a server endpoint: Authorization. 
OpenIddict.Server.OpenIddictServerDispatcher|INFO|The authorization request was successfully extracted: {
  "request_id": "the request id",
  "client_id": "my client id",
  "redirect_uri": "http://subdomain.domain-example.com/signin-oidc",
  "response_type": "code",
  "scope": "openid profile email",
  "code_challenge": "some value",
  "code_challenge_method": "S256",
  "response_mode": "form_post",
  "nonce": "some value here too",
  "state": "some value here too",
  "x-client-SKU": "ID_NET6_0",
  "x-client-ver": "6.30.0.0",
  "aud": "https://openid.external-domain.com/",
  "iss": "https://openid.external-domain.com/"
}. 
OrchardCore.OpenId.Services.Managers.OpenIdApplicationManager|INFO|Client validation failed because 'http://subdomain.domain-example.com/signin-oidc' was not a valid redirect_uri for the request id. 
OpenIddict.Server.OpenIddictServerDispatcher|INFO|The authorization request was rejected because the redirect_uri was invalid: 'http://subdomain.domain-example.com/signin-oidc'. 
Microsoft.AspNetCore.Routing.EndpointMiddleware|INFO|Executing endpoint 'OrchardCore.OpenId.Controllers.AccessController.Authorize (OrchardCore.OpenId)' 
Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker|INFO|Route matched with {area = "OrchardCore.OpenId", action = "Authorize", controller = "Access"}. Executing controller action with signature System.Threading.Tasks.Task`1[Microsoft.AspNetCore.Mvc.IActionResult] Authorize() on controller OrchardCore.OpenId.Controllers.AccessController (OrchardCore.OpenId). 

Problem here is that something is overriding the https to http.

OpenIdServer Hosting Setup (Behind Proxy)

I have OrchardCore project running on IIS 2019. I enabled the Reverse Proxy Configuration feature and enabled the X-Forwarded-* headers.

This app is running on openid.internal-domain.net and is not accessible to the outside traffic. On another server, I have an app running on IIS 2019 server that redirects traffic from external domain openid.external-domain.com to openid.internal-domain.net. My reverse proxy sets the X-Forwarded-Host and the X-Forward-Proto and X-Forwarded-For as expected.

Here is the app settngs. as you can see the app scheme is set to https

Reverse proxy server variables which shows how I am setting the proto to https

Here are the /.well-known/openid-configuration from the server when accessed externally.

{
  "issuer": "https://openid.external-domain.com",
  "authorization_endpoint": "https://openid.external-domain.comconnect/authorize",
  "token_endpoint": "https://openid.external-domain.comconnect/token",
  "introspection_endpoint": "https://openid.external-domain.comconnect/introspect",
  "end_session_endpoint": "https://openid.external-domain.comconnect/logout",
  "revocation_endpoint": "https://openid.external-domain.comconnect/revoke",
  "userinfo_endpoint": "https://openid.external-domain.comconnect/userinfo",
  "jwks_uri": "https://openid.external-domain.com.well-known/jwks",
  "grant_types_supported": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types_supported": [
    "code"
  ],
  "response_modes_supported": [
    "form_post",
    "fragment",
    "query"
  ],
  "scopes_supported": [
    "openid",
    "offline_access",
    "email",
    "phone",
    "profile",
    "roles"
  ],
  "claims_supported": [
    "aud",
    "exp",
    "iat",
    "iss",
    "sub"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "code_challenge_methods_supported": [
    "S256"
  ],
  "subject_types_supported": [
    "public"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "introspection_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "revocation_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "claims_parameter_supported": false,
  "request_parameter_supported": false,
  "request_uri_parameter_supported": false,
  "authorization_response_iss_parameter_supported": true
}

[MikeAlhayek]

@kevinchalet is this an issue in OrchardCore or the OpenIdConnect library?

[kevinchalet]

It’s essentially the same root cause as your last question: your OC client app is not configured to restore the HTTP scheme from the forwarded headers and the MSFT OIDC handler thinks the request didn’t use HTTPS and creates an incorrect ˋredirect_uri`.

Try to enable the "proxy" feature in your OC client app hosted in Azure.

[MikeAlhayek]

Now I am confused :)
I did enabled it and enabled Reverse Proxy Configuration and enabled X-Forwarded-Proto and that worked.

Why would my client app need to worry about proxy settings. The client app is hosted on Azure and is only running on https. this app is not running behind my proxy server at all.

[kevinchalet]

The client app is hosted on Azure and is only running on https. this app is not running behind my proxy server at all.

It's not your proxy server, but your client app is definitely running behind a reverse proxy, you're just not realizing it (otherwise, enabling the "proxy" module would have no effect 😃)

In this case, the reverse proxy is managed by Microsoft and is used to do TLS termination before the web worker has even a chance to handle the requests. In the past, it was performed using Application Request Routing (ARR) but I heard they moved/are moving to YARP (which is why it's basically driven by Azure's needs these days).

That's the problem with cloud offers: you generally have no idea what happens under the hood 🤣

[MikeAlhayek]

Thanks for your help! This differently puzzled me.