Support for HTTP in Development Environment with IdentityServer - Handling Scheme Mismatch and Redirect Issues

[z0rimo]

Which version of Duende IdentityServer are you using? 7.0.10

Which version of .NET are you using? 8.0

Describe the bug When using IdentityServer in a development environment with HTTP instead of HTTPS, several components such as the Discovery Document, redirect URI validation, client request parameters, and server URL handling incorrectly assume HTTPS. This mismatch leads to potential failures in client authentication and redirection.

To Reproduce

1. Set up IdentityServer in a development environment using HTTP instead of HTTPS.
2. Generate the Discovery Document (/.well-known/openid-configuration) or attempt to perform client redirection.
3. Observe that URLs within the Discovery Document incorrectly reference HTTPS.
4. Note that HTTP URIs may fail validation checks, and client request parameters might not reflect the correct scheme being used by the client.

Expected behavior IdentityServer should handle HTTP environments gracefully during development by correctly reflecting the HTTP scheme in all generated URLs, redirect URIs, client request parameters, and server URL settings.

Proposed Solution To address these issues and ensure that HTTP environments are supported during development, I implemented custom versions of several IdentityServer components. Here are the customized components and their key modifications:

1. DiscoveryResponseGenerator: Adjusts URL schemes within the Discovery Document dynamically based on the client's scheme.

2. RedirectUriValidator: Ensures HTTP URIs are considered valid during redirect URI validation.

3. ClientRequestParametersProvider: Aligns client request parameters with the actual scheme used in the environment.

4. ServerUrls: Manages server URL configurations dynamically to ensure the correct scheme is used.

Would it be helpful if I provide the actual code implementations I used to solve these issues? If so, I can include the relevant snippets for further discussion.

Additional context This issue is particularly relevant for developers working in environments where HTTPS is not used, such as during local development or certain staging setups. Native support for easier HTTP handling in development environments would reduce the need for extensive custom implementations and improve the flexibility and usability of IdentityServer.

[RolandGuijt]

OpenIdConnect relies on a protected transport to function securely. Additionally, it is explicitly mentioned in the specification that the discovery document should use HTTPS.

Because of that we don't recommend to use IdentityServer without HTTPS. But it should still work with HTTP. You could try the following:

• Use an HTTPS certificate in your developer environment (dotnet dev-certs)
• When configuring IdentityServer disable the requirement for HTTPS metadata: options.RequireHttpsMetadata = false;
• Check if there's middleware that redirects to HTTPS (UseHttpsRedirection, UseHsts)

[RolandGuijt]

@z0rimo Did this work out for you? If so I'd like to close the issue.

[z0rimo]

@RolandGuijt Thank you for your detailed response! I really appreciate the helpful information. Also, I’m sorry for the late reply.