The redirect URI always uses HTTP instead of HTTPS

[savissimo]

Describe the problem

The redirect URI always uses HTTP instead of HTTPS. As a consequence, the login page fails to load, since the redirect URI is not among the allowed ones.

What was the expected behavior?

The redirect URI follows the scheme of the URL of the document the request came from, or it should be possible to specify the scheme. per request.

Reproduction

• I followed the Quickstart guide for .NET Core MVC. Everything works in local dev, even if I use a custom DNS name instead of localhost.
• I dockerized the project and deployed the container on to Heroku.
• Visit (http://test-auth0-ss.herokuapp.com) to see a public page. Go to /account/profile (not linked in the page) to request a page that needs authorizations.
• You'll be redirected to (https://4funsimracing.eu.auth0.com/authorize), but the redirect_uri field causes the issue.

Environment

• Auth0.AspNetCore.Authentication version 1.0.3
• .Net 6
• No dependency is involved in the authentication/authorization flow.

[frederikprijck]

Thanks for reporting.

This hasnt come up as an issue before. And I believe our SDK does nothing specific with the redirect Uri that would cause this.
Could you provide a reproduction using our sample at https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/master/Quickstart ?

That would allow us to help investigate what is causing this.

[savissimo]

I've tried to deploy to Heroku your sample app, but somehow it cannot start. From Heroku's logs, I get this:

2022-06-01T13:03:17.655006+00:00 heroku[web.1]: Starting process with command `dotnet run`
2022-06-01T13:03:22.531375+00:00 heroku[router]: at=error code=H20 desc="App boot timeout" method=GET path="/" host=test-auth0-ss.herokuapp.com request_id=822182d9-bfe5-495c-b401-654bef4d8293 fwd="45.33.231.226" dyno= connect= service= status=503 bytes= protocol=https

Then the app goes to "crashed" status. This might be because I've deployed it on a free dyno, which may have lower specs.

If you wish to take a look at a minimal repro, which I refererred to in my initial post, I've uploaded it here: (https://github.com/savissimo/test-auth0-aspnetcore). If you want to see it in action, I'll re-deploy it on Heroku (currently it's serving your sample app).

[frederikprijck]

Can you elaborate what heroku has to do with any of this?

You should be able to try the sample I shared locally.

[savissimo]

Sorry that I was not clear before. I have no issue when using localhost, or any other public DNS name that points to my machine (a dev server exposed on the internet). However, when I deploy to Heroku I get this behaviour. The app is configured for HSTS and HTTPS redirection, which works on Heroku, but the redirect_uri on Heroku is always HTTP (it's HTTPS instead on my dev server).

[frederikprijck]

Can you reproduce the behavior locally with HSRS and HTTPS redirection?

[savissimo]

No, I cannot. The redirect URI is always HTTPS in local, if I login from https://myapp/path, where myapp is either localhost:xxxx or a publicly available DNS name. The redirect URI is HTTP if I login from http://myapp/path, as I would expect.

Note that I've found a workaround, so this issue is not blocking me now, but I'd much rather come to a better understanding of what causes it. The workaround is, of course, "forcing" the redirect_uri by passing it to the LoginParameters property during AddAuth0WebAppAuthentication.

[frederikprijck]

I don't think our SDK does much with the redirect uri, other than passing it to the OIDC middleware, I think we should be looking at Microsoft's middleware and why it's not able to detect HTTPS.

• The redirect uri is configurable in our SDK using the CallbackPath, which defaults to /callback when omitted, see: https://github.com/auth0/auth0-aspnetcore-authentication/blob/main/src/Auth0.AspNetCore.Authentication/AuthenticationBuilderExtensions.cs#L76
• This CallbackPath, which is relative, is then used in Microsoft's Oidc middleware: https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authentication/OpenIdConnect/src/OpenIdConnectHandler.cs#L387
• The above will call BuildRedirectUri, which you can see here https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authentication/Core/src/AuthenticationHandler.cs#L174

In BuildRedirectUri, you can see it creates the entire Url, including using Request.Scheme. I would expect Request.Scheme to be incorrect in your case, would you be able to verify that?

[savissimo]

Thank you @frederikprijck, I'll try to find that out as soon as I have the time to add logs and deploy.

[savissimo]

Ok, I've recovered the code (it was on a different pc) and I've uploaded it to Heroku. This is what I got (notice the two Debug- headers):

It looks like the server is not detecting the Scheme correctly. This happens even before being redirected to OIDC, and I "fixed" that by rewriting the redirect URL. However, even if the redirect goes to https://.../account/login, the next redirect includes the http://.../callback URL, which is probably due to this same issue.

I'll try to research into that. Do you have any idea why the Request.Scheme is http even though the requested URL is HTTPS?

[frederikprijck]

I think this could be related to how HSTS and HTTPS Redirection is set up. I am not too familiar with it in the sense that I can be very helpful, but looks like unrelated to our SDK.

[frederikprijck]

Closing as I don't think there is anything we can do.

[anandrathnauni]

Usually in cloud infra, you'd have a LB in front of the spring-boot-app. The traffic from browser to this LB will be HTTPS, but the traffic from this LB to your spring-boot-app will be http, thats why scheme detections is http. There are configurations in application.properties you can add to apply LB's headers. I think its called server.forward-headers-strategy

[ctolkien]

I think we're hitting this issue as well. We are running in a container as http, but the public endpoint is https. We're forwarding the XForwardedProto header, which would normally resolve this, but it doesn't appear to being picked up. We're continuing to do some more digging here.