I've been hacking with this for a long time, and whilst I think nginx can technically do it, it's likely to be over-complicated and problem-prone (see the comments about "ifs are evil" in the nginx doco).

Instead, I've used Apache. It's still something of a project to do, but RewriteCond and RewriteRule allow for the permutations needed. Apache has some annoying defaults with regards to setting X-Forwarded-* headers which we have to overcome. Apparently setting X-Forwarded-Host and/or X-Forwarded-Server trips up FusionAuth in some way.

However, I think I've got this working (or rather, I've got it working as well as I can see, and my in-development app can log in too). I've raised a PR on fusionauth-contrib: https://github.com/FusionAuth/fusionauth-contrib/pull/2. There may be more edge cases for API users I haven't considered here - comments welcome.

I've had a look at the github issue @dan posted, and in fact a few others. They all seem to be pretty worthwhile. The hoops I've jumped through here are excessive, and the differences in headers set by Nginx and Apache also tripped me up - all stuff that's not clearly documented or described in FusionAuth. There's definitely something to do here that would really help all of this. I'm not yet sure if the existing issues will solve this, or if another needs raising.

Either way, I hope my PR will save someone else the 1-2 days I've spent hacking about with this!? Thanks all for your help getting this far.

I've been hacking with this for a long time, and whilst I think nginx can technically do it, it's likely to be over-complicated and problem-prone (see the comments about "ifs are evil" in the nginx doco).

Instead, I've used Apache. It's still something of a project to do, but RewriteCond and RewriteRule allow for the permutations needed. Apache has some annoying defaults with regards to setting X-Forwarded-* headers which we have to overcome. Apparently setting X-Forwarded-Host and/or X-Forwarded-Server trips up FusionAuth in some way.

However, I think I've got this working (or rather, I've got it working as well as I can see, and my in-development app can log in too). I've raised a PR on fusionauth-contrib: https://github.com/FusionAuth/fusionauth-contrib/pull/2. There may be more edge cases for API users I haven't considered here - comments welcome.

I've had a look at the github issue @dan posted, and in fact a few others. They all seem to be pretty worthwhile. The hoops I've jumped through here are excessive, and the differences in headers set by Nginx and Apache also tripped me up - all stuff that's not clearly documented or described in FusionAuth. There's definitely something to do here that would really help all of this. I'm not yet sure if the existing issues will solve this, or if another needs raising.

Either way, I hope my PR will save someone else the 1-2 days I've spent hacking about with this!? Thanks all for your help getting this far.

I've been looking at something similar here too. I'd like to ensure that hitting up auth.site1.com can only "see" the "site1" tenant. Likewise, auth.site2.com can only get to the "site2" tenant.

I've got some distance with this. When I hit up the root (or in fact any URL) I can have Nginx add in a tenantId=xxx query string parameter. This seems to work, in so much as FusionAuth returns the correct tenant login screen (confirmed by styling changes to each tenant). As Nginx is doing this out of the reach of the user, there's no way a user could get to the wrong FusionAuth tenant - although there are some things a user can do which I'd rather they couldn't.

There is one problem I can't seem to solve though. That is, if you hit up the root of auth.site1.com, you get a redirect to /login. That then redirects to oauth2/authorize, along with some cookies and a query string which includes the client_id.

The problem I have is that the client_id returned always seems to be the FusionAuth one (ie. the 'root') - even though it's not in the correct tenant. This leads to a confusing outcome because you can't log on with the users in the tenant. If I correct the client_id, then all is well.

It seems to only solution is to have Nginx intercept the query string, correct the client_id and then pass the request along (additionally including the tenantId=xxx query string variable). This is somewhat at the edge of what an Nginx reverse proxy can do, so it's looking like that FA redirect with the wrong client_id might just be the end of this endeavour (unless maybe I add in LUA into nginx or something similar).

Thanks all for this - I too fell into the trap. It looks like the docs I was following have the wrong signature for the exchange_o_auth_code_for_access_token function: https://fusionauth.io/blog/2020/07/14/django-and-oauth

It should of course read:

r = client.exchange_o_auth_code_for_access_token(
      code,
      settings.FUSION_AUTH_APP_ID,
      redirect_url,
      settings.FUSION_AUTH_CLIENT_SECRET,
    )

(incidentally, the docs use CLIENT_ID in this function call, but never actually try to set it - so it should be APP_ID as here)