What do developers want from a CIAM solution?
Heya,
So, what do developers really want from a customer identity and access management (CIAM) solution?
I think it is the same thing developers want from any software solution. I don't think it's quite as simple as what Keith wrote, but I think he's on the right track.
First, though, it is silly to treat developers as a monolithic block. I haven't seen an updated version of Five Worlds, but even within the web development space, there are at least four types of developers:
Front end (which you could further divide into front end frameworks and vanilla JS)
Backend (which you could further divide into back end languages and frameworks)
Full stack
Devops (deployment engineers)
Each of these want different attributes from a CIAM solution, just as they do from any piece of infrastructure. To almost every developer, a CIAM solution is no different than a caching layer, a datastore, or an API gateway.
It's a tool to be used to make a developers life easier.
So, how can you do that?
Make it easy to get started. This means free to use and preferably a free SaaS. Lots of folks know how to use docker to stand up a server, but a SaaS that they don't have to maintain is even easier.
Make it easy to integrate. No CIAM solution stands on its own, any more than a database would. So, whatever the integration is, make it as easy as possible. You can wrap the integration into an SDK, but it's even better if it plugs into existing OIDC compatible solutions that a developer is already familiar with. Whether that is a standalone library like Ruby's Omniauth or functionality built into a dominant framework like the .NET OpenIdConnect, meet developers where they are at.
Follow the Pareto principle. Most of CIAM is about logging in, registration, MFA and federation/social sign-on. Have this dialed.
Design for extensibility. Auth has a lot of sharp edges and there are weird things developers might want to be able to do. Whether that is a peculiar user model, the ability to overlay their own UI so they can have the look and feel just how they want it, or extension points in login flows, the CIAM system can't handle every single use case.
Don't break backwards compatibility. A CIAM system is integrated into an existing application or applications as a one time effort. Then the developers go back to doing their "real" job, which is delivering features that have business value. Breaking changes will cause pain instead of easing it. They might even cause developers to consider other solutions.
In the same vein, be secure. This is really foundational. CIAM systems are safeguarding really important data. If that data is lost there can be real world monetary and legal consequences.
Keep improving. Like any other tool, developers expect forward progress from their CIAM solution. It should keep improving, making their lives better and easier.
Be in it for the long haul. The same way that developres need backwards compatibility and security, they need to trust that a project/tool/company will still be there. Of course, some developers care more about this than others, but no one wants to build on a foundation of sand.
Now, as a CIAM provider, you can emphasize different features or aspects of the above to tune your solution for different kinds of developers. For example, if you offer a terraform provider, that will speak to the integration needs of backend developers. Whereas if you offer a set of React SDK components, front end developers will appreciate that kind of integration. For all aspects, there is a spectrum of acceptable effort and different points on the spectrum will speak more to different kinds of developers.
If you are looking for developers to adopt your CIAM solution, rather than offering it as a top-down solution being sold to CIOs, make sure you understand what developers want.
Cheers,
Dan