The road to APIness in customer identity

Being conservative, I’d say in the last five years, the Identity Access Management (IAM) sector has seen some major changes. We have gone from the closed directory type environments, which were (fairly) straightforward when on-boarding users, to mass adopted open consumer systems, with the type of demographic, UX designers dread. It has all happened a bit quickly. The result has been somewhat of a lag in recognition of the complexity of such systems. In has only been in the two years or so that analysts, normally at the forefront of technological advances, have started to look at customer identity as an entity in its own right. That is not to say that the murmurings of market movement have not been felt in the IAM space. Identity-as-a-Service (IDaaS) is crossing the security barrier, with Gartner predicting implementations to reach 40% by 2019 – IDaaS having a more flexible model for external access requirements. The new direction of an outward looking, all encompassing IAM infrastructure, is now opening its doors to the customer or consumer. This is creating a sub-set of IAM known as Customer Identity Access Management or CIAM.

CIAM is a fruition of a multitude of changes: from Internet uptake to broadband availability to consumer expectations. It has meant that enterprises, SME’s, not-for-profits, governments, and so on, all have the same problem – how to service myriad identity use cases with high degrees of security and assurance, whilst making the user experience wonderful.

Enter, the Universal Identity API or UIAPI.

The answer to CIAM: an API approach?

CIAM is the mothership of all identity types. It has to potentially cope with demographics, as wide as a country, whilst at the same time having robust web security. It’s a hard balance to get right. To make matters worse, CIAM platforms, often need to be used in a multitude of service types and customer expectations. Let me give you an example that is based on a real-world scenario. An identity system was to be built on the premise of a variant of SAML 2.0 that was non-standard. An out-of-the-box IdP would struggle with this and would require a back-end change to handle the SAML response expectation. This would mean that the development team behind the IdP would have to essentially hard-code the solution. This in itself would be fine, if annoying, but this is only one of potentially many bespoke changes an IdP would need to make to fit complex customer based identity. This means that to get something ‘right’ you would be in almost perpetual development mode. This benefits no-one in the long term.

To manage the many faces of customer and citizen identity, vendors have looked to adding in API capability to their solutions. The problem is that in doing so, they have not been ambitious enough in their architecture and design. They have effectively created point solutions, albeit API-based, but all the same, they only address certain areas of the overall CIAM ecosystem.

CIAM, the recipe for success: ditch the platform

An API approach is the right answer to the question of servicing myriad use cases. However, it isn’t the API that is at fault here, it is how that API functions. Let me use an analogy. If you are making a cake, you have certain ingredients you need to make a Victoria sponge, and you add in certain others to turn it into a chocolate cake. If you don’t have any cocoa powder or chocolate, then you won’t be able to make anything other than a plain Victoria sponge – no matter how wonderful the sugar, eggs, and flour are. It is the same with an API. If you restrict your API functionality, to say, authentication, then that will restrict the flexibility around the use cases your platform has to accommodate.

In fact, let’s go crazy and ditch the platform altogether! Hang on I hear you shout, don’t go mad! There is method in this madness and it is called an ‘API Recipe’ using a ‘Universal Identity API’.

If you move away from the closed mindset of having a static platform you open up new possibilities for CIAM. If, instead of constraining your API approach to point API functions, you turn your platform into an API, then you have the ability to add in some cocoa powder, or even a touch of cinnamon to the mix. This new approach to identity is called an API Recipe. Using a recipe based approach to mix and match identity-based functions, gives you much more flexibility in handling a variety of customer based use cases.

How to bake an IdP

Here’s a recipe for an IdP:

1 cup of OpenID Connect ½ cup of authentication ½ cup of verification services Add a sprinkle of account manager

Mix together, add in a few endpoints and some rules, and bake inside a decoupled user interface for 2 hours.

And another for a Personal Data Store:

1 and ½ cups of data store functionality (secure data sharing) 1 cup of account manager ¾ cup of authentication ⅓ cup of blockchain based consent receipts ¼ cup of external services such as document capture

Mix together with rules on a low user interface setting for 4 hours

Flexible requirements need flexible approaches

The above may seem like a silly way of developing an IDP for a consumer system. But this type of flexible architecture is what is needed to give us the level of dynamism and functionality needed to address the ever-changing consumer identity needs of a modern CIAM solution.