Where Should Your User Profile Data Live?
Heya,
There are two patterns I’ve seen work effectively for handling user profile data when an application uses a CIAM (customer identity and access management) system.
The first option is to use your CIAM system to solve only the user authentication problem. The CIAM stores minimal user profile data, possibly only a login identifier and credentials. Everything else is stored in the application.
Credentials may involve additional factors of authentication or be pulled from an external source of identity data, but no application specific profile data is stored in the CIAM system. After authentication, the CIAM system vouches for the user to the application, often with a token, and the application owns every other interaction with that user.
The second pattern stores profile data in the CIAM system. It will expose this data via UI or API. The profile data can then be accessed by other actors:
your application(s)
end users
employees (especially customer service reps)
other data processing systems
Profile data will have different access rules and patterns. There may be preferences directly owned and editable by the end user, customer notes only visible to employees, or behavioral data only accessible by software.
Very few CIAM systems manage 100% of what’s known about a user in their system. CIAM systems often have integration functionality that lets you push user data into other business systems.
These two approaches have different tradeoffs.
In the authentication-only case, your user profile data sits right next to your application data, which helps with analytics, joins, and removal. You also have more options when it comes to leaving your current CIAM provider as you’re less entangled with them.
Another benefit: you own the representation of the user profile data. You aren’t limited by how your CIAM system structures it. Some CIAM providers, such as Auth0, have profile attribute limits.
The flip side of this power is you’re now responsible for storing, securing, and building interfaces for all the actors to interact with and manage that profile data. You’ve also got sensitive user information sitting in two places under laws like GDPR or CCPA: the credentials and login identifier in the login system, and the rest of the private data in your application.
The final downside is that you’re basically reinventing the wheel when it comes to well understood user flows like profile management.
Which would you choose? Well, I’ve seen both approaches work fine, and you can migrate between them, so it’s not a one-way door.
Some things I’d think about when choosing:
What does your CIAM system actually provide? Does it offer flexible, friendly interfaces for your users, your employees, and your systems to interact with profile data? If not, that’s a pretty clear signal you should build your own user profile system.
How often are your end users or employees going to be changing this data? Is it relatively static? Can you avoid building some of the UI or APIs?
What’s the quantity of the profile data, and how important is it to the business? If all you’re doing is surfacing a bit of data after login, that matters less than if you’re progressively profiling a user and tracking many preferences and interactions over time.
How much development effort does it take to build UI and APIs, and is that a good use of your developers’ time? What is the opportunity cost?
Finally, how much do you trust your CIAM provider, and how likely are you to want to move to a different one down the road? This is an impossible question to answer authoritatively, but you should consider it, given how sticky CIAM solutions are. It’s a lot easier to migrate a system that’s just login identifiers and credentials than one where you’ve built on top of a CIAM system and your users are used to interacting with it directly.
Either one can work. Think about which fits your application best.
Cheers,
Dan