Windows Authentication popup always shows when accessing my site with https

[mercedesprats]

IdentityServer version

7.1.0

.NET version

8.0.404

Description

Some time ago we opened this: DuendeArchive/Support#1435

At that time, it was solved by adding the domains as local intranet at Windows Internet Options. The thing is that by that time we had our identity MVC application started in a separate host (Kestrel) than the one we used for our main application. We have recently changed that so it starts in the same host and port that our application does (under the path /identity) and we got again the same issue and it seems that solution doesn't work anymore and get again the Windows Authentication popup.

These is how we intialize our identity:

And the schemes we use for authentication:

Reproduction steps

Our main LoginDefault endpoint in the AccountController has the [Authorize(AuthenticationSchemes = NegotiateDefaults.AuthenticationScheme)]. If we access it with https it is automatically called using HTTP2, which does not support Negotiate and the popup shows.

If we close the popup, even without writing any credentials, the browser automatically does again the call downgrading the protocol to HTTP1, getting to our logging page.

It only happens the first time you enter as the next times seem to be always through HTTP1.

Expected behavior

We would like to know if there's a way to not show the popup without having to force HTTP1 protocol when starting our kestrel host.

Thank you!

Logs

No response

Additional context

No response

[RolandGuijt]

The components used for this are Microsoft's. I recommend to post an issue on their support systems. I'm sorry but unfortunately we can't support them here. An alternative would be to use our consultancy services. For more details please contact us.

[RolandGuijt]

A colleague suggested you could have a look why the call to AddBasicAuth is there. It might conflict with the JWT bearer handler.

[RaulRG]

Hello Roland, thank you for your answer. What do you mean by these are Microsoft's components? When we configure Windows authentication to be used in IdentityServer, aren't we using your product? I thought IdentityServer was taking care of integrating with Windows. Could we someday use a Linux based server with IdentityServer an use Windows Authentication? Sorry for all these questions, but we used IdentityServer in the first place to solve the authentication "task" and not implement something ourselves.

[RolandGuijt]

IdentityServer is a framework for ASP.NET Core. It provides OAuth/OIDC functionality on top of what is already there in ASP.NET Core. The second part of the code you posted that registers all the handlers/schemes is actually all ASP.NET Core.

Can you please try removing AddBasicAuth if possible and see if that helps?

[RaulRG]

We removed AddBasicAuth and got the same result. I am by no means the expert, I am just the one with the budget :-)
As I see it, my understanding of the role of IdentityServer was not complete. I thought we would use the OAuth/OIDC protocols against IdentityServer and it would take care of all the "magic" internally. Now I understand that it is taking care of authentication when we use username / passwords stored in our database and when using EntraID as external provider (or is this ASP.NET as well?), but Single Sign On with Windows is not being done by you (this is 95% of our customers as of today, as we deploy an on-premises system)

[RolandGuijt]

That is correct. IdentityServer is designed to be as flexible as possible. The reason is that we found that every organization has its own requirements on where user data comes from and what external providers are used just to give two examples.
When IdentityServer is used and configured in an ASP.NET Core application it will provide the endpoints and surrounding protocols to make it an OAuth/OIDC compliant identity provider.
For the rest, like user management and external providers like EntraID and Windows authentication, you are free to use whatever you want. For external providers the most obvious way to configure them is by using the support Microsoft has for them with the built-in ASP.NET Core support. All the code you posted under "And the schemes we use for authentication:" is using Microsoft libraries.

As mentioned, we can help with that but it is not part of the support we give here.

[RolandGuijt]

Not related to the topic, but just a tip:

I see you are configuring a fixed X509 certificate as the source of the key material. We recommend using our automatic key management feature if you are on the business edition or higher.