Allow additional trusted hosts during callback redirect

[axieum]

During development, our Django backend runs at http://localhost:8000/ while the frontend is at http://localhost:5173/.

The following host verification code restricts the redirect to the current request's host.

django-auth-adfs/django_auth_adfs/views.py

Lines 54 to 59 in 9415d8a

	url_is_safe = url_has_allowed_host_and_scheme(
	url=redirect_to,
	allowed_hosts=[request.get_host()],
	require_https=request.is_secure(),
	)
	redirect_to = redirect_to if url_is_safe else '/'

Could it be possible to merge in Django's ALLOWED_HOSTS setting so we can redirect them back to the original client that may be at a different host?

[tim-schilling]

I'm curious why specifying the redirect via state doesn't work as a workaround?

[axieum]

At present, the view decodes the redirect URI from the state but since the redirect is to a different host than the Django application itself, it replaces it with /.

This issue requires that we can add more allowed redirect hosts, so we can redirect away to the frontend application that may be at a different host.

[axieum]

Could it be possible to merge in Django's ALLOWED_HOSTS setting so we can redirect them back to the original client that may be at a different host?

Instead of using Django's setting, I think a dedicated setting in the AUTH_ADFS namespace would be more secure and flexible.

[tim-schilling]

I think using Django's ALLOWED_HOSTS setting would be reasonable. It feels overly redundant to create a separate setting. I would be open to creating a get_* method on the view to fetch it so it's easier for other devs to restrict/customize it in the future. @JonasKs thoughts?

[JonasKs]

I haven’t written Django frontends for probably 5 years, but why would they be hosted on a different URL/port? Is this because of use of e.g. DRF and single page frontends?

If so, the frontend should fetch tokens using PKCE flow, and send the token as a header to the backend.

[axieum]

Originally I had Remix frontend handle SSO and then forward the ADFS JWT with every API call using the provided AdfsAccessTokenAuthentication authentication backend. However, I noticed it was making lots of database calls with each request to sync the Django user (and groups) with the JWT contents.

So now we are looking to piggyback off the existing Django session cookie since it's accessible by both the backend and frontend.

• example.com/api › Django ASGI
• example.com › Remix

It's just that during local development, it runs on a different port at localhost which isn't allowed redirect destination.

• localhost:8000 › Django ASGI
• localhost:5173 › Remix

For now we are logging into Django to set the session cookie, and then manually going back to the Remix app. Works a treat.

As for third-party's using the Django API - they go through an API gateway which handles their Oauth2 token exchanging, etc.

[JonasKs]

I see. I'm a bit unsure of the security implications of merging a SPA into ALLOWED_HOSTS, as it's used to protect from host header attacks, @tim-schilling. Maybe there is none?

Since this is a dev-problem, an alternative could be to allow any configured host when DEBUG is on? I'd prefer not to introduce extra settings and pit falls to production environments. Most security incidents are due to configuration issues.

[tim-schilling]

I was imagining this being useful for a services based approach where you authenticate against login.domain.com and then are redirected to app.domain.com.

I'm not sure about the security implications of that. I would imagine if you're in charge of both hosts, it should be fine. I don't see these concerns as possible if that's the case:

Django uses the Host header provided by the client to construct URLs in certain cases. While these values are sanitized to prevent Cross Site Scripting attacks, a fake Host value can be used for Cross-Site Request Forgery, cache poisoning attacks, and poisoning links in emails.

Additionally, it looks like request.get_host() is the piece that validates the host against ALLOWED_HOSTS. Forwarding those along makes sense in some cases.

[PolSpock]

Hello, it looks like I have a similar issue:
I'm trying to implement MS Azure authentication for my Django Rest Framework application.
I have correctly set my reply URL in MS Azure for my development localhost address: http://localhost:60069/oauth2/callback

But each time I try to authenticate, I get redirected to the non-port version of my URL and receive an error in my console:
ERROR:django_auth_adfs:ADFS server returned an error: AADSTS500112: The reply address 'http://localhost/oauth2/callback' does not match the reply address 'http://localhost:60069/oauth2/callback' provided when requesting the authorization code.

If I remove the port in my dev context (both in Azure and my Docker configuration) to switch back to the default port 80, everything works fine.

Is this normal ?

Regards

Edit : Indeed, it was off-topic since my issue was caused by my reverse proxy. The config.py -> redirect_uri() with request.build_absolute_uri was building my URL without including my port

[tim-schilling]

@PolSpock please don't use other issues for support needs. It's better to create another issue and reference the other. If they are indeed duplicates, the new one can be closed.

Regarding your specific error, the issue is that your Entra/AD configuration needs to account for http://localhost:60069/oauth2/callback. Note the port specifically.

[Funklesworth]

I haven’t written Django frontends for probably 5 years, but why would they be hosted on a different URL/port? Is this because of use of e.g. DRF and single page frontends?

If so, the frontend should fetch tokens using PKCE flow, and send the token as a header to the backend.

In my case, I've ran into this issue due to requiring a non-ascii host for our site which Entra ID doesn't allow.

We have set up an ascii equivalent host for auth purposes but trying to set that as state fails the request.get_host() check and get's rewritten to "/" and the entra id auth fails.

[nwp90]

Turns out that there's probably no solution to the problem with Entra unless MS enable IDN in the redirect URI. If you send it a redirect URL which doesn't match the origin your browser sends, MS won't set Access-Control-Allow-Origin at the end of the auth process, and it will fail anyway.