You'll need to have some kind of mapping between the tenant/application/client_id and the referrer/hostname value.

You can maintain this in a number of places, but at some point in the code, foo.example.com needs to be turned into 9d92ca33-bc7b-4d13-acd7-f7dc06038396 or whatever the application id is. (Typically the application id will be enough if you are doing just authentication/authorization. If you are doing more user management, you may need the tenant id. The principles are the same.)

And the same thing needs to happen with bar.com.

Some FusionAuth users perform this mapping at the network proxy layer, using nginx or somethign similar. If you self host, that is an option.

You can store this mapping in your own datastore and expose this mapping as an API to be retrieved in middleware.

You can pass this data from the initial authorize request to the token retrieval request (commonly called oauth-redirect in our example apps) using the state parameter and then do the lookup there.

You can also store that value in FusionAuth on the systemConfiguration.data field.

It's really an implementation choice, but at the end of the day, there's no automated mapping between the hostname where the user facing application lives and which FusionAuth application corresponds to it.

We do have an open feature request that would do this mapping (see point 5 in this issue) but it is not on the near term roadmap.