Agen.co enables organizations to securely expose enterprise context to internal agents, copilots, and AI workflows through an identity-aware control layer that governs access, reduces risk, and centralizes oversight.
A low-code CIAM platform for managing customer identity as you scale.
Empower your workforce with secure agents
Customer identity and access management (CIAM) controls how customers register, sign in, join organizations, receive access, administer their accounts, and leave a product. In B2B SaaS, CIAM also has to represent each user’s relationship to one or more customer organizations and preserve the correct tenant context throughout every access decision.
That broader model changes the architecture. A successful login does not prove that a user may access a particular invoice, project, report, API object, or administrative action. The application still has to check the active tenant, the user’s membership and permissions in that tenant, and the tenant that owns the requested resource.
This guide explains the complete system, the responsibilities a CIAM platform can take on, the controls that remain in application code, and the tests worth running before choosing or shipping a solution.
CIAM is the set of systems and processes used to register and authenticate customers, recover accounts, manage users and organizations, supply authorization context, automate identity lifecycles, and delegate safe administration in a customer-facing product. Some CIAM programs also need consent and preference controls, identity proofing, fraud prevention, and abuse defense.
The exact scope varies by product. At minimum, a useful CIAM system should answer five questions:
CIAM is therefore larger than a login box. Authentication is one component. A production system also needs account recovery, user and organization management, authorization, provisioning, administration, and lifecycle controls that continue to work after the first successful sign-in.
B2B SaaS CIAM has to model organizations as first-class security boundaries. One person may belong to several customer accounts, hold a different role in each, and switch between them during the same workday. The application must keep identity, membership, active tenant context, permissions, and resource ownership separate.
Consider a consultant who belongs to Tenant A as an administrator and Tenant B as a viewer. The email address and user identity may be the same in both accounts, but the memberships are different. Switching to Tenant B should establish a Tenant B context; it should not carry Tenant A’s administrative authority into the second account.
Collapsing these concepts into one user record creates predictable failure modes. Removing the person from one customer may disable the identity everywhere. A role intended for one tenant may be treated as global. A valid token may pass authentication while application code returns an object owned by another tenant.
There is no single identity model for every SaaS product. Choose one deliberately:
A B2B CIAM architecture has five connected parts: identity and authentication, tenants and memberships, lifecycle provisioning, authorization and entitlements, and administration with audit evidence. Each part changes on a different schedule, has a different owner, and can fail while the rest of the identity system appears healthy.
Identity and authentication establish who the principal is and how it proved control of an account or credential. The layer may support passwords, passwordless methods, social login, passkeys, multi-factor authentication, and enterprise SSO through SAML or OpenID Connect. It should also cover recovery, verification, and session creation.
Enterprise customers may authenticate through a tenant-specific SAML or OIDC connection; other accounts may use app-managed password, passwordless, passkey, or social-login flows. When the relevant modules and permissions are enabled, a customer administrator may configure its tenant’s connection and apply an allowed account-level MFA policy. The SaaS provider retains control of enabled methods and baseline policy; some mappings require provider-side management or API configuration.
OIDC adds an identity layer on top of OAuth 2.0 and defines claims about an authenticated end user. SAML can also carry authentication assertions between an enterprise identity provider and a service provider. Neither protocol decides whether a user may read a specific row in the SaaS application.
Tenants represent customer organizations; memberships connect identities to those organizations. A user can have several memberships, each with its own status and access context. A secure model resolves one active tenant for the request, confirms the membership, and keeps tenant-scoped authority separate from the user’s global identity.
Account hierarchies add another layer. A parent organization may administer subsidiaries or business units, but inheritance should be explicit. “Parent” must not become shorthand for unrestricted access to every descendant resource. Define which actions inherit, which resources remain isolated, and where a tenant administrator’s authority stops.
See the dedicated account hierarchy guide for hierarchy and delegated-administration design, and the multi-tenant architecture guide for broader data-isolation patterns.
Lifecycle provisioning aligns identity and membership state as people join, change roles, move between groups, or leave a customer. Invitations and just-in-time onboarding can create access during sign-in. SCIM can synchronize users and groups, including group-membership changes, from a directory. Any resulting tenant-membership behavior depends on the product’s connection model and lifecycle contract.
SCIM 2.0 standardizes an HTTP-based protocol for provisioning and managing identities across domains. It does not, by itself, define the application’s access-token invalidation, retry policy, reconciliation schedule, or handling of a delayed event. Those behaviors require an explicit implementation contract.
The lifecycle design should cover more than creation. Teams need to decide how to handle group changes, membership removal, account suspension, account deletion, event replay, partial failure, and identities that no longer belong to any tenant.
Authorization decides whether the active principal may perform an action on a resource. Entitlements decide which product capabilities are available under a plan, feature assignment, or account-specific grant. The two can interact, but they answer different questions and should not be hidden inside one undifferentiated “access” flag.
RBAC is useful when permissions map cleanly to roles. Relationship-based access control can express access through ownership, teams, projects, or account hierarchies. Entitlements can represent commercial availability. Many applications need more than one model, with documented precedence and a clear enforcement point.
The complete authorization guide covers policy models, enforcement placement, list filtering, freshness, and failure behavior in detail. The CIAM layer can supply verified identity and tenant context, but application code must still enforce resource ownership and the requested action.
Administration gives the SaaS provider and its customer administrators the controls appropriate to their scope. Common tasks include inviting users, managing groups, configuring SSO or SCIM, assigning roles, and reviewing identity events. Audit evidence should record relevant changes without implying that every application authorization decision is logged automatically.
Provider and customer administration should use separate boundaries. A tenant administrator should manage allowed settings for that tenant, not global product configuration or another customer’s records. The portal itself also needs authorization, because an administrative UI is another route to sensitive operations.
Audit requirements should name the evidence needed: who changed a setting, which tenant it affected, the previous and new values, the source of the change, and the effective time. Application-specific authorization decisions may require a separate decision log or business audit trail.
Core B2B CIAM covers customer authentication, organizations, lifecycle, authorization context, and delegated administration. Other capabilities depend on the product’s users, regulations, abuse exposure, geography, and availability requirements. Treat them as explicit evaluation dimensions rather than assuming every CIAM platform implements them or that every SaaS product needs the same depth.
CIAM protects access to customer-facing products, while workforce IAM manages employee and contractor access to internal systems. The protocols can overlap, but the operating models differ. CIAM must support customer-controlled organizations, external administrators, product-specific onboarding, tenant-scoped authorization, and user volumes or experiences that the SaaS provider does not centrally manage.
Some companies use the same upstream enterprise identity provider for both. That does not make the two systems interchangeable. A customer’s workforce IdP may authenticate its employees to your SaaS product, while your CIAM layer still has to map them into the correct customer account and product-access model.
For a deeper comparison, see CIAM versus IAM.
A CIAM provider can manage authentication, organization records, provisioning integrations, policy data, and administration workflows. The SaaS vendor remains responsible for product security, application resources, business authorization, and correct integration. Customer administrators configure only the controls delegated to their tenant; they do not define the provider’s global trust boundary.
Technical responsibilities:
Governance controls:
This division should appear in the design review and the vendor evaluation. If a responsibility has no named owner, teams often assume the identity provider handles it. That assumption is especially dangerous for database scoping, queue consumers, caches, exports, and server-to-server operations.
A tenant-safe request has a short chain of proof: authenticate the principal, establish the active tenant, validate current membership, evaluate the requested action, and constrain data access to the authorized resource scope. The authenticated session or token supplies identity context; it does not replace the application’s resource-level authorization or data-isolation checks.
A safe B2B CIAM boundary: the identity layer establishes authenticated tenant context; the application validates membership, resource scope, action, and query scope. Identity events and application decisions produce different evidence.
A useful decision contract contains at least:
For a single-object request, the invariant is straightforward:
allow only if membership(user, active_tenant) is valid and resource_scope_allows(active_tenant, resource) and authorization_allows(user, action, resource)
Same-tenant ownership should be the default. A hierarchy, shared workspace, or cross-account collaboration feature may permit a broader resource scope, but only through an explicit, authorized relationship that the application evaluates. A client-supplied tenant ID must never create that relationship.
List operations require more care. The application should constrain the query to the authorized resource scope before returning rows, totals, facets, exports, or cursors. Filtering unauthorized rows after retrieval can still leak counts, ordering, aggregate values, or pagination state.
The same rule applies outside an HTTP request. Background jobs, cache keys, search indexes, analytics exports, file paths, webhooks, and message-queue consumers need an explicit tenant boundary. A global user ID or a valid signature alone is not enough.
CIAM state changes at different speeds. A directory update, group change, tenant switch, role assignment, token refresh, cache invalidation, and application-side cleanup may not happen in one transaction. Secure designs define which source is authoritative, when access is re-evaluated, and what the application does while state is stale or unavailable.
Do not infer immediate revocation from an administrative screen changing state. Access tokens, refresh tokens, sessions, caches, and application replicas can have different lifetimes. The proof-of-concept should measure the actual behavior and compare it with the risk of each protected action.
A CIAM platform is usually the better choice when identity has become a product subsystem rather than a login feature. Multiple enterprise connections, customer-managed administration, multi-tenant membership, lifecycle provisioning, authorization models, SDK maintenance, migrations, and audit needs create ongoing operational work that a homegrown service must own indefinitely.
Building can still make sense when the requirements are narrow, the organization has sustained identity expertise, or a platform would impose a data model or runtime dependency the product cannot accept. Compare the continuing cost of security maintenance, enterprise connections, support, migrations, and incidents with the effort needed to ship the first authentication flow.
Include migration and exit costs in both directions. A platform evaluation should cover data export, identifier mapping, staged migration, rollback, API coverage, and the work required if the application later changes providers.
Use a representative tenant to validate architecture fit, runtime behavior, integration paths, administrative boundaries, and commercial limits under normal and failure conditions. A feature checklist cannot show whether tenant context survives a switch, whether stale authority persists after a change, or whether application data remains isolated across every access path.
Vendor claims such as “real time,” “multi-tenant by design,” “highly available,” or “easy to integrate” should lead to a request for evidence. Ask for the measurement method, reference architecture, failure behavior, working API example, and commercial terms that make the claim true for your use case.
A CIAM proof of concept should test the happy-path login, security boundary, and operating model. Use a representative tenant, realistic roles, one complex enterprise connection, and application-owned resources. Record the expected result before each test so a successful authentication cannot hide a failed authorization or lifecycle check.
Use the highest-risk cases as explicit negative tests:
CIAM failures usually appear at the boundaries between systems. Authentication succeeds, but the wrong tenant is active. Provisioning updates identity state, but application permissions remain stale. A detail endpoint is protected, but a list or export leaks metadata. The platform works, while application code assumes guarantees the platform never made.
A user may belong to several tenants. Deleting one membership should not be implemented as deleting or disabling every relationship associated with the identity. Keep global identity state separate from tenant membership, and define what happens when the final membership is removed.
A URL, form field, header, or request body can express which tenant the client wants to use. It should not be the authority. Resolve the active tenant from authenticated context, verify membership, and compare it with the resource owner before performing the operation.
Protecting GET /projects/{id} does not protect GET /projects, dashboard totals, exports, autocomplete, or cursors. A list can expose another tenant even when every detail endpoint is correct. Scope the query before data leaves storage, and test totals, ordering, facets, and pagination metadata as carefully as rows.
GET /projects/{id}
GET /projects
Membership, role, and group changes may outlive a token, session, cache entry, or application replica. Document the acceptable stale window, decide which sensitive actions require a fresh check, and measure the provider’s real runtime behavior. An administrative screen showing the new state does not prove that every access path has applied it.
Self-service is useful only inside a fixed boundary. Separate tenant configuration from environment-wide policy, define which settings customer administrators may narrow, and prevent them from expanding beyond provider defaults. Authorize every administrative operation on the backend, even when the interface hides controls that the current administrator should not use.
Identity and administration events do not necessarily explain every application access decision. A complete investigation may also need the active tenant, action, resource, policy version, decision, and enforcement result. Decide which questions an incident reviewer must answer, then collect the missing product and authorization evidence at the application enforcement point.
Frontegg models customer organizations as accounts or tenants within an environment, and a user can belong to multiple accounts while retaining the same user identity. Its documented integration paths cover hosted and embedded login, enterprise SSO, SCIM provisioning, tenant switching, roles and permissions, ReBAC, entitlements, self-service administration, and identity audit events.
Frontegg’s architecture documentation describes environments, accounts, sub-accounts, and users. The token-claims documentation explains the available identity and tenant context, while the documented account-switching flow refreshes user state and obtains a JWT for the selected account.
For lifecycle management, Frontegg documents SCIM provisioning for users and groups, including group-membership changes. Authorization options include roles and permissions, relationship-based authorization, and entitlements. Frontegg’s current roles documentation states that role changes reflected in JWT permissions take effect after the current token expires and a new token is issued; this should not be treated as immediate active-token revocation. The Admin Portal can expose configured self-service modules subject to the product’s permissions and setup.
Those capabilities do not remove the SaaS vendor’s responsibility for application-resource isolation. Backend services still need to validate authenticated context, enforce action and resource checks, and scope tenant-owned data correctly.
Explore the Frontegg CIAM platform for the product overview, or start with the developer quickstart for an implementation route.
Start with the account and membership model, then define the trust boundary between identity context and application data. Choose the authorization model, write the lifecycle contract, and turn the highest-risk assumptions into proof-of-concept tests. Only then compare platforms against the complete system your product has to operate.
Use these deeper guides for the next design task:
