When accessing the site from https, the openid related address becomes http

[hyzx86]

When I use the following address to access the configuration information returned is as follows:

https://saas.test.com/test1/.well-known/openid-configuration

The odd thing is that other tenants in the same app don't have this problem .
I did not configure any site addresses, including the OpenId Server authority properties

Also tested, the authority attribute only affects the issuer's value

{
    "issuer": "http://saas.test.com/test1",
    "authorization_endpoint": "http://saas.test.com/test1/connect/authorize",
    "token_endpoint": "http://saas.test.com/test1/connect/token",
    "introspection_endpoint": "http://saas.test.com/test1/connect/introspect",
    "end_session_endpoint": "http://saas.test.com/test1/connect/logout",
    "revocation_endpoint": "http://saas.test.com/test1/connect/revoke",
    "userinfo_endpoint": "http://saas.test.com/test1/connect/userinfo",
    "jwks_uri": "http://saas.test.com/test1/.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": [
        "plain",
        "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
}

[hyzx86]

Hi @kevinchalet , Can you help me look at this problem? Thanks!

[hyzx86]

Done ,
Since I enabled the reverse proxy through Nginx, I need to enable the reverse proxy function in OC. After enabling the reverse proxy function, the problem has been solved, thank you!

[hyzx86]

This problem has reappeared in the latest version of OC 2.x. The reverse proxy does not work.
Turning on reverse proxy doesn't help.
The SPA client is using the https protocol

request url :
https://saas.netabp.com/testsite/.well-known/openid-configuration

response :

{
    "issuer": "http://saas.test.com/testsite",
    "authorization_endpoint": "http://saas.test.com/testsite/connect/authorize",
    "token_endpoint": "http://saas.test.com/testsite/connect/token",
    "end_session_endpoint": "http://saas.test.com/testsite/connect/logout",
    "userinfo_endpoint": "http://saas.test.com/testsite/connect/userinfo",
    "jwks_uri": "http://saas.test.com/testsite/.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": [
        "plain",
        "S256"
    ],
    "subject_types_supported": [
        "public"
    ],
    "token_endpoint_auth_methods_supported": [
        "client_secret_post",
        "private_key_jwt",
        "client_secret_basic"
    ],
    "claims_parameter_supported": false,
    "request_parameter_supported": false,
    "request_uri_parameter_supported": false,
    "authorization_response_iss_parameter_supported": true
}

[hyzx86]

relate #13816

[hyzx86]

Hi @kevinchalet @MikeAlhayek , Has anything been tweaked since upgrading to OC 2.x?

My project data comes from OC 1.8.x and I am trying to upgrade to OC 2.0.x latest
I'm using oidc-client-ts on my SPA client , and the main configuration is as follows

  const config = {
    userStore: new WebStorageStateStore({
      prefix: `oidc_${appSettings.clientId}_`
    }),
    authority: 'https://saas.netabp.com/testsite',
    client_id: appSettings.clientId,
    redirect_uri: appSettings.clientRoot + '/auth/redirect',
    post_logout_redirect_uri: appSettings.clientRoot + '/auth/logout_redirect',
    scope: 'openid profile email roles offline_access',
    filterProtocolClaims: true,
    loadUserInfo: true,
    automaticSilentRenew: true,
    response_type: 'code'
  } as UserManagerSettingsStore;

The above configuration automatically requests the
https://saas.netabp.com/testsite/.well-known/openid-configuration
Note that the schema above uses https.

But strangely enough, the configuration information returned is all http, as I mentioned above:#14874 (comment)

[MikeAlhayek]

I am guessing your are running your site behind a reverse proxy of some sort.

Try enabling the Reverse Proxy feature and then able the then enable both the X-Forwarded-For and the X-Forwarded-Proto settings

[hyzx86]

Try enabling the Reverse Proxy feature and then able the then enable both the X-Forwarded-For and the X-Forwarded-Proto settings

You're right, I do use the reverse proxy feature, but I've switched it on and off repeatedly and it doesn't work, it worked in 1.8, but 2.x doesn't do anything!

[MikeAlhayek]

@kevinchalet I can confirm the same issue here. Is there a new settings that we need to change?

[github-actions]

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.

[kevinchalet]

@MikeAlhayek nothing has changed in OpenIddict that could cause that, so there’s either a regression/breaking change in the proxy module or in ASP.NET Core/the forwarded headers middleware.

I’ll take a look.

[MikeAlhayek]

@kevinchalet I am not sure if this is related or not. I am running an OC project (older version probably 1.3) and using OpenId server. this site is running on IIS. When I visit Authorization server under the "Encryption Certificate Store Location" or "Signing Certificate Store Location" I see no warnings.

But on the OC instance 2.0 running on Azure using docker container, I am seeing a warning.

Here is a screenshot of the server settings from the over OC running on IIS

Here is a screenshot from the server settings from the Azure environment

Maybe the fact that it is running in a docorized enviornment alter some behaviors?

[hyzx86]

I'm guessing that for some reason similar to the Middleware execution order, the schema attribute has not been processed by the reverse proxy when it is read from the current request message
I'm not sure, I went to check the code but didn't find a similar configuration.

When the Authority address is specified manually, it applies the Authority URL correctly, but other endpoints still use http

[kevinchalet]

@kevinchalet I am not sure if this is related or not.

Maybe the fact that it is running in a docorized enviornment alter some behaviors?

Yeah, I'd bet it's completely unrelated and simply caused by the fact you're using Docker.

I'm guessing that for some reason similar to the Middleware execution order, the schema attribute has not been processed by the reverse proxy when it is read from the current request message

Yup, I agree. #13181 (comment) has changed the order of the authentication middleware from 0 to -150 but has not updated the order of the reverse proxy module, which is still -1. The OpenIddict server integrates using an IAuthenticationRequestHandler service that is called by the authentication middleware: since the forwarded headers middleware is now registered too late in the pipeline, it has no effect on the requests processed by OpenIddict.

I guess we could tweak the order of the reverse proxy module, but as for the authentication middleware, there's a risk we could break something else (@Piedone was right when he said it was a risky change 🤣)

/cc @Skrypt @hishamco

[kevinchalet]

When the Authority address is specified manually, it applies the Authority URL correctly, but other endpoints still use http

It's expected. See openiddict/openiddict-core#1613 for the reasoning.

[MikeAlhayek]

@kevinchalet I am going to submit a PR for this. What about Cors module? I think that one should always be loaded early on, right?

[Piedone]

I'd think yes.