Feat: Possibility of Routing to Company IdP Based on Email/Company Name and Group-Specific API Tokens

[KaanMol]

Hi!

I want to start by saying how much I appreciate your work on Rauthy! It's a fantastic project, and I have a feature request that I’m curious about.

Would it be possible to implement functionality where, based on the user's email or company name, they could be routed to their organization's Identity Provider (IdP)? I’m envisioning something similar to how providers like Okta handle this. Whether this is done through a single login screen, an API, or some other approach, I’m interested in your thoughts on whether this functionality could be added.

I noticed Rauthy supports grouping, but I’m not sure if that would be suitable for organizations or if there’s a more appropriate solution for this use case.

Additionally, would it be possible to generate API tokens specific to a group or organization? This would allow me to hand out tokens to specific groups so they can interact with my API.

If this sounds like a useful feature for Rauthy, I’d be happy to contribute to its development. Let me know if it’s something you’d consider or if you have any recommendations for achieving this functionality.

Thanks again for all your hard work on Rauthy. Looking forward to hearing your feedback!

[sebadob]

I want to start by saying how much I appreciate your work on Rauthy! It's a fantastic project, and I have a feature request that I’m curious about.

Thanks a lot!

Would it be possible to implement functionality where, based on the user's email or company name, they could be routed to their organization's Identity Provider (IdP)? I’m envisioning something similar to how providers like Okta handle this. Whether this is done through a single login screen, an API, or some other approach, I’m interested in your thoughts on whether this functionality could be added.

I don't really get what you want to achieve. When you just want to redirect users to other IdPs, what do you want Rauthy for in the first place, when it should only redirect and don't do anything else?

I guess dividing the deployment into multiple companies resembles to what Realms in Keycloak are. I decidided to intentionally not include this additional abstraction layer into Rauthy to not overload it with stuff that you don't need most of the time. Rauthy is so efficient, that the idea in such a case is, that you just deploy multiple instances, which makes the whole thing a lot simpler.

Multiple deployments show a clear separation between companies even for someone that doesn't know anything about it, because you could directly see it when looking at the deployment name, namespace, or however you separate instances. You also get dedicated admin UI branding matching each company.

Additionally, would it be possible to generate API tokens specific to a group or organization? This would allow me to hand out tokens to specific groups so they can interact with my API.

This is solved automatically as well if you just have multiple deployments. Another bonus probably is, if you don't unify all of them in a single place where you could mess up something with a bad configuration (because we're all just human), it is also more secure out of the box.

[KaanMol]

Well, it is the same idea as the Social Providers like GitHub, the difference would be that when you enter an email it gets triggered, instead of clicking on the button "Login with GitHub" or something. Maybe I explained it a bit wrong. Rauthy would still give the options to have a second factor etc.

It could even be a button as "Login with SSO" and after that you have to fill in a company name or your email before the right login screen can be given etc

[sebadob]

Ahh okay, got it. So you would like an option that basically forces a user, depending on the E-Mail domain, to a specific IdP, which would at the same time make it impossible to use Rauthy directly, even if the account will exist after the first login anyway?

A specific "Login with External" or whatever would be a lot simpler to implement, but this could be easily misleading I guess.

I don't really know about your exact use case and setup, but something else that comes to my mind when thinking about this issue is, if it would be a solution for you, if you could redirect your "company specific" users to a 2nd login screen. My first idea would be, that they don't get redirected to /auth/v1/authorize?... but rather to something like /auth/v1/company?... (which would not work with OIDC auto-discovery of course). Rauthy always has the last sucessfully used E-Mail for a login available to make the current login flow more user friendly. This route though could redirect automatically depending on that value and show maybe a dropdown or similar with pre-defined companies to choose from, so they get redirected.
And if they want to use Rauthy's login, I would not even bother re-creating the current login form, but just show a button which would redirect them to the original /auth/v1/authorize?... instead.

Showing a pre-defined list with companies to choose from would get you into trouble with EU privacy laws and leaving this input completely up to the user will lead to massive amounts of support requests, because they will get it wrong many times for sure. This would leave you with "do an automatic redirect if E-Mail matches xyz".

Another solution could be a different behavior based on a given query param when redirecting to /auth/v1/authorize.

This whole thing would be nothing small to implement though. The commpany-specific API tokens would also mean a huge amount of additional checks in many places. I am not really sure if all this work is actually worth it in the end. Achieving something like that would be a lot easier with internal realm separation like Keycloak does it, which I decided against on purpose in the beginning.

Just to get an idea about your situation, how many different companies are we talking about and why would a "deployment per company" not work for you?

[KaanMol]

Ahh okay, got it. So you would like an option that basically forces a user, depending on the E-Mail domain, to a specific IdP, which would at the same time make it impossible to use Rauthy directly, even if the account will exist after the first login anyway? The company itself would set those settings basically.

What I want to do on my end (this doesnt have to be fully in Rauthy), they create an organization, specify that members of their company can login, also provide the details of the provider etc. Employees or other users can then login and directly get assigned the right roles etc.

Honestly, what I try to achieve is maybe not something in the scope of Rauthy, it would be something like Clerk, Auth0, Okta etc. Github also has a similar setup. I rather have it on one server instead of multiple deployments. But I would totally understand if it too much of an overhaul

[sebadob]

So you want SSO as a service. I cannot recommend Rauthy for this at all. It has never been designed with this goal in mind.

In fact, if I would design SSO as a service, I would do some fundamentally different design decisions. Rauthy does not and never will fit this role well. It's using static config whenever it makes sense to be as fast and ressource efficient as possible. It should be easy to operate with a small footprint. Yes, it can handle millions of users pretty easily, but this is the case because of many decisions that have been made, which make it even less fit the SSO as a service role. There are many more reasons and even the core database design should look very different in that situation.

You could try to make it fit into that role, but only with another application on top, something like an orchestrator / proxy that deploys separate Rauthy instances per customer, but doing everything inside the same Rauthy deployment will most probably never make you happy.