Question about OIDC SSO in a multi client/tenant scenario. reddit / selfhosted ---------------------------------------------------------------------- andrewsmd87 · 2023-11-21 15:07 We are building out an OIDC SSO integration with another business where we will be the IDP. We're a B2B company so it's actually us SSOing people on behalf of multiple clients. The probelm we will have is clients can theoretically have ID collisions as we treat each client as their own instance. From what I understand, within our OIDC request, we would have one client id, and call back url regardless of if we're trying to SSO someone in from customer a or customer b. Any suggestions on how to handle this? My thoughts are the party we are integrating with either has to have a unique url for us to hit per client, which we would then handle in a config, or we have to send a custom claim that is basically, which client is this. I don't think any of the standard claims are meant for this, but I could be interpreting it wrong. Just wondering if anyone has been through this and what they ended up doing. ---------------------------------------------------------------------- sk1nT7 · 2023-11-21 16:55 Not an expert but Authentik supports various methods to onboard users (Social login via GitHub, Azure AD or LDAP etc.). So this would be the way to onboard your tenants. Their users somewhat have to be onboarded into your IdP platform. Either manually (bad idea) or via Azure/LDAP/Google etc. Afterwards, your IdP platform (here Authentik) will be configured as IdP at a 3rd party application. Here, Authentik also provides various methods like SAML etc. For such a SAML provider you can enable or disable various sources from which your tenant users were onboarded or actively synched. Don't think there will be an issue with unique IDs but honestly, no real experience setting up such larger IdP stuff. My two cents ---------------------------------------------------------------------- andrewsmd87 · 2023-11-21 17:16 So let me try to explain a little better. We are a SaS product where each client gets their own instance. Clients have customers we call candidates. What I'm trying to figure out is how we would SSO someone over to this third party with ID 1234 but for client A. Or SSO the same person over with ID 1234 but client B. The client context matters because they will see different things on the third party's end. That's where I was thinking either they need a uinque url for us to SSO to per client, or we need to send a custom claim saying, send them to x client's dashboard in your system. Not seeing how what you're mentioning above tackles that but I may be misunderstanding. Appreciate the input! ---------------------------------------------------------------------- from-nibly · 2023-11-21 17:24 I think the general approach is to have a separate subdomain for separate clients clienta.mycompany.com and clientb.mycompany.com What you are doing is becoming okta or auth0. Do the same things they are doing. ---------------------------------------------------------------------- sk1nT7 · 2023-11-21 17:44 Thanks for outlining it in more detail! I may be totally wrong but are you as IdP not simply ensuring that person A prooved his identity. The authorization and access controls, what the user will and can see/do/access at the other party is up to the other party. You just provide a unique claim such as a user's ID and then the other party must choose what to do with it regarding permissions, access controls, group assignments etc. The user itself remains the same, it should be a matter of the third party's application whether the user can actually authenticate and access resources. I may still not get the actual SSO flow and your requirements though. Sorry if that's the case. Just writing what I am thinking. ---------------------------------------------------------------------- andrewsmd87 · 2023-11-21 20:40 Sorry, I don't think I'm being clear mainly b/c I was trying to obfuscate things but I can try and share some more. Whenever we have a new client, we add them into our environment and keep a separation of data via everyone's own database. Part of that are their candidates (customers) getting ids within our system. Given that we seperate that out in the database layer, it is possible that bob smith who is a reddit candidate has the id 1234 It is also possible that jane doe, who is a meta candidate has the id 1234. Those are unique to us because they are in different databases. However, in an OIDC request, the ID (subject) we would be sending over would just be 1234 in both cases. So we have to have a way when we send bob to say, bob is 1234 and needs to see reddits instance in their system, but jane 1234 needs to see's meta's instance in their system. I think that is where the non standardness comes because we can't ensure unique ids across clients, but are wanting to send all of this from one IDP, as opposed to one IDP per client. Make sense? ---------------------------------------------------------------------- andrewsmd87 · 2023-11-21 23:27 Hey just wanted to update you so you don't waste any more time! I spoke with some technical people at the third party and they can provide a unique URL to call per client so that is problem solved. Thanks again for your help!