CIAM Platform Architecture

Short answer. A CIAM platform runs sign-up, sign-in and access for your customers. Judge one by its building blocks, how it is deployed, how you customize it and what it exposes to your own systems.

What is a CIAM platform?

A CIAM platform is the system that runs sign-up, sign-in and access for your customers. It stores customer identities, signs them in, issues the tokens your applications trust, and gives you and your customers' administrators the tools to manage it all.

What is CIAM architecture?

Most CIAM platforms share the same building blocks:

• Identity store: where customer accounts, profiles and organizations live.
• Authentication and token services: OpenID Connect sign-in, OAuth 2.0 tokens and SAML assertions.
• Sign-in experience: hosted pages or your own pages, with MFA and passwordless options.
• Policy engine: decides who may do what.
• Administration: a console for your team and delegated views for customer administrators.
• Events and APIs: how the platform talks to the rest of your systems.

Deployment models

• Multi-tenant SaaS: the vendor runs one service for many customers, with logical separation. The vendor operates the infrastructure; integration and configuration remain yours.
• Dedicated SaaS: the vendor runs a separate instance for you. More isolation, usually at higher cost.
• Self-managed: you run the software on your own infrastructure. Full control, and full operating effort.

SecureAuth offers all three: multi-tenant SaaS, dedicated (private) SaaS and self-managed on-premises.

Configured, coded, or orchestrated

• Configured: you set up flows and policies in an administration console. Fast, with limits on what you can change.
• Coded: you call APIs and SDKs and write custom logic. Flexible, with more to maintain.
• Orchestrated: you design sign-in journeys in a visual flow builder. Visible to non-developers, and only as flexible as its building blocks.

Most platforms mix the three. In SecureAuth, you configure in the administration console, write policies in a visual editor or in Rego, and add custom logic with scripts that run after authentication or before tokens are issued.

Integration surface

Check what the platform exposes to your applications and systems:

• Standards: OpenID Connect, OAuth 2.0 and SAML for applications and partner identity providers.
• Administrative APIs: everything you can do in the console, available through an API.
• Events: changes delivered to your systems asynchronously, for example through webhooks.
• Custom sign-in pages: your own pages, if hosted ones are not enough.
• Provisioning: how accounts are created and removed from other systems.

Evaluating platform fit

1. Does the organization model match how your customers are structured?
2. Can you build your sign-in journeys without fighting the platform?
3. Does it connect to the identity providers your partners already use?
4. Can your systems receive the events and call the APIs they need?
5. Does the deployment model meet your isolation, residency and operating needs?

Frequently Asked Questions