An Interview With Alex Ward
Hiya,
This is another in my series of interviews about the future of CIAM from experts in the space.
Alex Ward is a freelance auth consultant and fiction writer in Portland, Oregon. He runs and maintains authomnibus.com. Alex first became fascinated with auth protocols when working at a white-label social networking company after being tasked with implementing SAML. After spending a lot of time reading the spec and dissecting SimpleSAMLPhp, he was hooked and has worked on auth systems in between other roles for nearly two decades. When not consulting, he spends his time making Tabletop RPGs, writing dark fantasy stories, and spending time with his wife and 3 cats.
I’m excited to hear Alex’s views on CIAM, identity, authorization and more.
Dan: What problems do you see customer identity and access management (CIAM) solving for your customers?
Alex: I work with a wide variety of folks, ranging from smaller companies primarily doing B2B SaaS products all the way up to large enterprise organizations with millions of B2C accounts across multiple CIAM solutions depending on their business unit. I think the common denominator when either they’ve already got a CIAM in place or when they’re looking for me to help them evaluate one, is that authentication is complex. They want a trusted system that can handle all the ways a customer can authenticate, and they want it done securely. Past that, they tend to have more complex requirements like account joins, connecting with customer IdPs, MFA, step-up auth, configurable automated security checking, and the like.
Silent login and SSO are also really common requirements. Those are tricky to implement safely from scratch and harder to maintain without some sort of CIAM system in place.
So overall, I tend to see an evolution from having a single username/password user base stored in a single SaaS application to needing something to manage users across properties; there are just a ton of benefits to having a centralized CIAM to handle that once you grow past a certain size.
Another thing that maybe is a little underrated: having a CIAM means you’re probably using a standard protocol (OIDC/OAuth2) on each of your end applications, and that makes you a lot more flexible than rolling your own identity APIs, especially if you ever need to do a partner integration or if you suddenly find yourself having to bridge identity after an acquisition or merger.
Finally, managing data residency and all the associate compliance concerns around personally identifiable information across potentially multiple jurisdictions can be aided by a well-executed CIAM solution, especially from a trusted partner.
Dan: What are major challenges you see with CIAM (in the industry, in implementation, etc)?
Alex:
Two major things, for me.
The first is Passkey rollout. I think we need to see good adoption of the Credential Exchange Protocol (CXP and the associated format) before we can get to a good place with passkeys. The current situation for end users isn’t great because passkeys are locked into a single provider, and on the CIAM end we don’t have a great way to import the IdP side of the passkey so if you ever need to switch CIAMs you might have a much harder data migration than you otherwise would with hashed passwords.
This is especially important with discoverable keys on services that don’t want to collect user identifiers. If you don’t collect anything but the passkey but then can’t migrate the passkey you could find yourself kinda stuck. Otherwise, there are several sharp edges around implementing passkeys, and I think that we (meaning the industry as a whole) tend to underestimate all the edge cases. It’s like the Average Familiarity XKCD comic, but with Passkeys.
The second is navigating Digital/Verifiable Credentials (in the literal sense of those two W3C proposals). There seems to be an increasing appetite for digital age verification as well as digital credentialing, and Auth0 has had a demo out with Verifiable Credentials for a bit now. But doing so in an ethical and privacy-respecting way requires a lot of thought. CIAM vendors who want to implement authorization based on digital credentialing should be very careful about data minimization and ensuring equitable access. There are real risks of surveillance, censorship, and discrimination. We don’t want a world where only those who can afford an iPhone can have a drivers’ license, for example. The whole industry is well positioned to take effective, ethical stances on how digital credentialing functions and ensure that appropriate protections are implemented if we make sure to prioritize it.
I do think there’s also a lot of benefit there, and I’ve come at this from the American Healthcare system. Electronic Medical records, for example, would be quite useful for things like Vaccination records, but if used inequitably could be used to deny services. It’s a thorny problem, and I hope we tackle it well.
Dan: What excites you about the future of CIAM? Any predictions?
Alex: Passkeys are legitimately exciting, having a phish-proof credential is awesome. We just have more work to get there (also I’d also really like to see people allowing for non-discoverable keys, I don’t think we also need to get rid of usernames). I want us to get to a place where passwords are unnecessary, people can’t be tricked into sending over a MFA code to a scammer, and we’re all a little bit safer.
I also think there’s a lot of space to smooth out hybrid B2B and B2C use cases (or B2B2C if we want to get wild with the initialisms). Some CIAM systems are really focused on B2C, only a couple really focus on B2B, and everyone can do “both” but I think there’s some fun stuff we can do to offer better tooling for the case where one business holds the CIAM system and associated SaaS products, but another business needs to manage their little slice of tenancy.
Finally, I’m seeing some more movement in being able to deploy a CIAM solution into particular regions for data residency/privacy requirements, and I’m hopeful we’ll see a more robust solution to GDPR compliance than the Data Privacy Framework, which is privacy respecting and under the control of the human at the other end of the screen and ensure the controls remain in their hands.
Thanks again to Alex for sharing his perspective, and thanks to you for reading!
Dan