FusionAuth
Tenant Discovery as part of Universal Application
Tenant Discovery as part of Universal Application
Problem
Currently Universal Applications does not solve for Tenant Discovery so users still need to be provided with a OAuth2/Authorize link that has a specific Tenant Id on the URL. This means that FusionAuth cannot have a single universal login page that works across Tenants. You need to have a way to determine which Tenant a user belongs to before they get to the OAuth2/Authorize page and then append the Tenant Id to the Universal Applications Authorize link. So a FusionAuth customer needs to do integration work to make Universal Applications work as a single login page, currently Universal Applications just solves the need to consolidate multiple applications into one to make it easier to manage.
Solution
Have a single login page that works across Tenants for Universal Applications or a page for Tenant Discovery before a user gets to the OAuth2/Authorize page. Slack does something like this pretty well for having multiple Slacks you have access to.
Alternatives/workarounds
Currently you need a page in front of FusionAuth to determine the users Tenant with the User Search API. This may return multiple users (if the same person has accounts with the same email or phone number in multiple tenants) so the page should be prepared to deal with that case. It also is vulnerable to enumeration, since I can enter any email address I want and see if it has an account at the application.
You could also provide Users with a traffic control page in front of the OAuth2/Authorize page where a user selects their Tenant if you are not worried users knowing about others Tenants besides their own.
Or create hard coded links that users from different Tenants always go to but this does not really capture the want for customer who desire to use Universal Applications as a way to have a single login link for all of their users.
You could also send an email/text to the user that does the lookup and sends the links. That would prevent user enumeration at the cost of additional friction.
Additional context
There is complexity with duplicate users across multiple Tenants, how would it handle having 2 [email protected] users in two different Tenants. There is also the concern about just entering an email and seeing what Tenants a particular user might have access to, so maybe we send off an email to the user that contains the right links or we send them a code to punch in before they can see all the Tenants they have access to.
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.
I'm not sure how this would work with duplicate users across multiple Tenants, how would it handle having 2 [email protected] users in two different Tenants.
My initial thought is if that was the case, we'd show a list of tenants to that user, and let them pick which one to log into.
There is also the concern about just entering an email
This could be any verifiable identity (so phone as well as email). But I think this is a great idea (at least as a setting to enable/disable) to prevent account enumeration at the cost of additional friction.
Generally speaking this would be something a FusionAuth customer would need to build.
There are several reasons why we can't and probably shouldn't build a feature like this, a few of them are:
- It allows tenant enumeration, and possible user enumeration. Usually this is not desired.
- An ideal auth code grant requires a CSRF state of some sort usually sent in the
stateparam by the RP - If you want to use PKCE, again you need to have state on the RP side
This means if FusionAuth builds this page, the RP cannot have previously built this state to forward along to the IdP. If we built a page like this, in practice we'd have to know how to redirect back to the RP so they could generate this state, and then start the authorize request to the IdP.
I don't foresee FusionAuth ever building a page like this. As far as I know, this type of feature is not in scope for what Tenant Manager is supposed to be.
The feature could be useful, but in practice I think it would have to be built by a customer.
@robotdan thanks for the perspective. This is something that is regularly asked for by multi-tenant SaaS clients.
Another option would be to write an example app or supported component that would handle this functionality. (The latter would be easier for the customer, the former for us.)
It allows tenant enumeration, and possible user enumeration. Usually this is not desired.
Definitely something to be cautious about. Josh offered a workaround of "maybe we send off an email to the user that contains the right links" that would prevent user enumeration at the cost of additional friction.
To help with tenant enumeration, we could do what Slack does, which is only show tenants that you have previously logged into on a given device.
An ideal auth code grant requires a CSRF state of some sort usually sent in the state param by the RP
This page could take a CSRF parameter and pass it through; same with PKCE. Not perfect, but might be a good security/usability compromise.
This page could take a CSRF parameter and pass it through; same with PKCE. Not perfect, but might be a good security/usability compromise.
Perhaps, but this would assume that all possible outcomes of this page are handled by the same call back handler such that state could be created, persisted and forwarded to this landing page such that we could then forward it to the correct login page with this state.
A primary use case of tenant manager would be that each tenant is a separate customer, so having a single callback seems unlikely.
It is critical that the RP initiate the authorize request and be able to persist state.
Perhaps there are various ways to solve this, but ideally whomever builds this page, then performs a 302 redirect back to the app so it can build the authorize request. For FusionAuth to perform this, we'd have to build a mapping of tenant to RP initiating endpoint that we could redirect to.
That is possible, but it wouldn't be turn key, the user of FusionAuth would have to build out these initiating endpoints, or perhaps just one that can accept a tenantId and then build the authorize request back to FusionAuth.
And at that point, all we have provided is a landing page with a redirect handler. If that is all we want, this could be done on the / themed landing page today. Just write a bunch of JavaScript or modify that themed page redirect to an endpoint based upon the selected tenant that can build the authorize request back to FusionAuth.
Fair enough. Maybe an example application showing this would be enough. I just know this keeps coming up in calls for multi-tenant SaaS customers/prospects.