redirect_uri should use https:// instead of http://

This appears to be a client-library issue.

Environment details

• Programming language: ASP .NET Core
• OS: Windows
• Language runtime version: 5.0.102
• Package version: 1.52.0

Steps to reproduce

Here is my login endpoint:

    /// <summary>
    /// Starts the Google OAuth 2.0 flow for application sign in.
    /// </summary>
    [HttpGet("Login")]
    public IActionResult GoogleOpenIdConnectChallenge([FromQuery] string? returnUrl) {
      if (TryValidateReturnUrl(returnUrl, out Uri? uri) && uri != null) {
        AuthenticationProperties authenticationProperties = new AuthenticationProperties {
          RedirectUri = uri.AbsoluteUri,
        };

        bool isAuthenticated = User.Identity?.IsAuthenticated ?? false;
        if (isAuthenticated) {
          return Redirect(authenticationProperties.RedirectUri);
        } else {
          return Challenge(authenticationProperties, new string[] { GoogleOpenIdConnectDefaults.AuthenticationScheme });
        }
      }

      return BadRequest($"\"{returnUrl}\" is an invalid return url");
    }

Here is my authentication code in Startup:

      // This configures Google.Apis.Auth.AspNetCore3 for use in this app.
      services
          .AddAuthentication(options => {
            // // This forces challenge results to be handled by Google OpenID Handler, so there's no
            // // need to add an AccountController that emits challenges for Login.
            // o.DefaultChallengeScheme = GoogleOpenIdConnectDefaults.AuthenticationScheme;

            // This forces forbid results to be handled by Google OpenID Handler, which checks if
            // extra scopes are required and does automatic incremental auth.
            // options.DefaultForbidScheme = GoogleOpenIdConnectDefaults.AuthenticationScheme;

            // Default scheme that will handle everything else.
            // Once a user is authenticated, the OAuth2 token info is stored in cookies.
            // After a user is signed in, auto create an account
            options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
          }).AddCookie(options => {
            options.Cookie.SameSite = SameSiteMode.None; // The client is on a different domain to the server

            // options.Cookie.Domain
            options.EventsType = typeof(CustomCookieAuthenticationEvents);
            options.LoginPath = "/api/Account/Login";
            options.LogoutPath = "/api/Account/Logout";
          }).AddGoogleOpenIdConnect(options => {

            // HTTPS connection is required to use open id connect
            options.ClientId = _configuration["Authentication:Google:ClientId"];
            options.ClientSecret = _configuration["Authentication:Google:ClientSecret"];
          });

The bug occurs when you hit the endpoint and get a challenge response:

The value redirect_uri is set to http://zukte-qvdgm.ondigitalocean.app/signin-oidc instead of https://zukte-qvdgm.ondigitalocean.app/signin-oidc

This causes the following error message to appear:

[amanda-tarafa]

The package we are extending is Microsoft.AspNetCore.Authentication.OpenIdConnect.

You can do this challenge.Properties.RedirectUri = challenge.Properties.RedirectUri.Replace("https", "http"); but yes, at this point the URL is still htpps and that makes sense, the app does not know it is behind a reverse proxy.

But, I remembered about this other issue #1680 and most importantly my recommendation at the time which was to follow Configure ASP.NET Core to work with proxy servers and load balancers. The recommendation there (and notice this is not specific to OpenId or any form of Auth) is to use forwarded headers, which you seemed to have succesfully configured a few comments up, so I’m not sure what changed from there to now that forwarded headers is not enough for you anymore.

Bottom line here is, this is nothing that application code can solve. Nor our Auth library, nor Microsoft’s, etc. The application is sending the HTTPS URL for he redirect. When that redirect is executed by the browser (i.e. a request is made to the redirect_uri), is at the point of going through the reverse proxy where the information (HTTPS => HTTP) is lost, and there’s nothing that application code can do to change that behaviour, because application code will never get the request (it will fail before) unless forwarded headers are set up.

[amanda-tarafa]

We don’t build the retunr URL ourselves, instead we rely on Microsoft’s OpenId implementation which we extend. So this probably is a request better suited for them 😃.

Also, I think there’s nothing stopping you from grabbing the result of the Challenge and change the return URL yourself before returning?

I’m reopenning in case I’m missing something here, but if I understood correctly this is probably something we won’t do.