Being conservative, I\u2019d 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\u2019s, 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\u2019s 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 \u2018right\u2019 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 platformAn API approach is the right answer to the question of servicing myriad use cases. However, it isn\u2019t 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\u2019t have any cocoa powder or chocolate, then you won\u2019t 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\u2019s go crazy and ditch the platform altogether! Hang on I hear you shout, don\u2019t go mad! There is method in this madness and it is called an \u2018API Recipe\u2019 using a \u2018Universal Identity API\u2019.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 IdPHere\u2019s a recipe for an IdP:1 cup of OpenID Connect\u00bd cup of authentication\u00bd cup of verification servicesAdd a sprinkle of account managerMix 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 \u00bd cups of data store functionality (secure data sharing)1 cup of account manager\u00be cup of authentication\u2153 cup of blockchain based consent receipts\u00bc cup of external services such as document captureMix together with rules on a low user interface setting for 4 hoursFlexible requirements need flexible approachesThe 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.