Should You Pick A CIAM Solution That Implements Standards?
Heya,
When you are thinking about CIAM and how you are going to let your customers log in to your application, there is a lot to think about.
Ont aspect to consider is whether or not you are going to use a solution, whether commercial, open source or framework based, that adheres to standards such as OIDC and SAML.
While the answer to any technical question is almost always "it depends", there's a strong case to be made for choosing a CIAM solution based on standards.
First, though, what does "adheres to standards" even mean?
So You Say You Are Standards-Based?
For CIAM, it means that the solution implements the parts of the OIDC and SAML specifications required for your application’s needs. Both of these standards are large and have many SHOULDs (in the IETF RFC 2119 sense), so finding a solution that implements everything is not feasible.
Examples of standards based features that may be require for some implementations and not matter for others include:
private_key_jwt client authentication
encrypted SAML assertions
While you don’t need to know the exact technologies, you will want to understand your CIAM use cases to determine what functionality you need.
At a minimum, a CIAM system should support the Authorization Code grant and modern signing algorithms for the tokens and assertions. It should also support security improvements like PKCE and those recommended by OAuth 2.1.
However, even if you choose a solution that implements all the standards, there are still complications. There are many parts of a full-fledged CIAM system for which there are no standards. This includes functionality like:
required authentication workflows like account locking, self-service registration and account recovery
tenant and client management (there are standards for registering clients, but not for other management tasks)
identity verification (verifying who the user actually is, though the NIST digital identity guidelines offer some implementation guidance)
access control (there is some work on this taking place)
Even if you pick the most standards compliant solution, you're going to have proprietary integration work as well.
It is like a database; you can write SQL against almost any database, but there are large parts of managing an RDBMS that are not going to be standardized. These include performance tuning, advanced SQL features, and operating and securing the database.
Given all these caveats, why should you prefer solutions that implement standards? There are three main reasons:
security
interoperability
portability
Let's look at each of these in turn.
Security
Many eyes make for shallow bugs, and that is true for security issues as well. Many experts help build the standards, and discussion takes place on open email lists and at open conferences. These experts spend a lot of time thinking through the security implications of proposed solutions.
By picking a CIAM server which implements the standards, you get to free-ride on all that expertise.
Does this mean that there are no security flaws in the standards? Or that non-standard solutions can't be secure?
No! See the issues with unsigned JWTs and other vulnerabilities Brian Campbell from Ping talked about in 2022.
But, having plenty of smart people working on a solution means it is more likely that the end result will be more secure. The experts will have considered or experienced edge cases that other vendors may have not.
Implementing open standards means the vendors doing so benefit from the experience of people from all sizes of companies, from big ones like Google and Microsoft to experts at smaller companies or consultants.
Interoperability
Adhering to standards makes it possible to interoperate with existing libraries and applications. One of the reasons SAML will never die is that there are so many service providers out there; the network effects are strong.
When you choose a robust, mature standard like OIDC or OAuth, you also get the benefits of existing libraries. Almost every language has an OIDC library, making it easier to plug the CIAM solution into your application. Of course, you still need to implement the other functionality mentioned above, but at least core login functionality is handled.
You can also increase development velocity because your engineering team is more likely to have interacted with a standards based solution than with a proprietary one. This means that the concepts, nomenclature and integration points are more likely to be familiar to your engineers.
Portability
A standards based solution helps with portability.
Again, portability is definitely not perfect, just like security and interoperability aren't.
But, consider which solution will impose more pain if and when you do decide to migrate off of it:
a 100% proprietary solution
a solution that implements standards where it can, but offers proprietary solutions where it cannot
If you decide to migrate from CIAM solution A to solution B, there are four possible scenarios:
Solution A is proprietary and so is solution B. Surprise! You are going to have to reimplement everything that touches your CIAM system, unless solution B is compatible with solution A (unlikely).
If solution A is proprietary and solution B is standards based, or vice versa, you are in the same boat.
If both solution A and solution B implement standards like SAML and OIDC, then you can re-use some of the code and many of the concepts.
In all of these scenarios, you'll have to test solution B’s integration with your application extensively. At least with the last scenario there’s some level of re-use.
It is similar to the portability of SQL across databases: not perfect, but there's significant overlap in syntax and even more conceptually.
Why Does It Matter?
These all matter because CIAM is sticky; it doesn’t make sense to switch solutions regularly. You’ll be living with what you pick for a while. At the same time, CIAM is important to get right, since it is close to the end user experience.
Thanks,
Dan