Hey folks! I'm working on integrating SSO for my app with a partner company, and they want to use their own Identity Provider (IdP) to access our app. That sounds reasonable, right? We already have our own IdP set up, and I manage a custom user-specific attribute—our Unique UserID for each user. I'm familiar with setting up static claims for things like email and organization ID, which are pretty straightforward. But I'm stuck on how to handle user-specific claims, especially when it comes to sending our Unique UserID alongside the other standard claims during the login process. In the old days with on-prem Active Directory, you'd have to extend the schema or use custom attribute fields, but asking an external company to do that seems a bit much. Am I making sense? Any advice or clarification needed?
2 Answers
I think it might be easier if you create a mapping table in your app that connects the user object ID from the IdP with your Unique UserID. Relying on the IdP for custom claims can blur boundaries; imagine every app asking for similar unique claims! You can keep things tidy this way.
If your app will be popular among many partners, you might be complicating things unnecessarily. If organizations are okay with using emails as unique identifiers, you could just rely on that. Most IdPs handle sending custom claims pretty well. They even let you tweak these claims with their expression languages like Okta's. This does mean a bit more work, though. But I'm curious—what’s your UUID for, that email wouldn’t work?
Gotcha! That makes sense. Sometimes legacy choices can really drive new developments.
The UUID was initially tied to account creation processes and ended up being our main identifier in the app instead of using the email. Looking back, it wasn't the best design choice.
Thanks for this idea! I hadn't thought about a mapping table, but it does seem like it would keep things simpler. I'll pass it along to the developers for further discussion.