Amazon Cognito handles the core of B2B SaaS authentication well — user pools, MFA, social and SAML federation, and reasonable default security posture without building any of it from scratch. Where teams start evaluating custom auth instead is almost always around one specific set of B2B requirements Cognito doesn't handle as cleanly out of the box: multi-tenant organization switching, SCIM-based provisioning for enterprise customers' IdPs, and fine-grained per-tenant role models.
What Cognito Does Well for B2B SaaS
For straightforward B2B auth needs — user signup/login, MFA enforcement, password policy management, and SAML/OIDC federation with a customer's IdP for SSO — Cognito's User Pools and Identity Pools cover the ground efficiently, with AWS handling the security-critical parts (token issuance, session management, MFA flows) that are genuinely risky to build from scratch. For most B2B SaaS products, especially earlier-stage ones, this is the right default.
Where Multi-Tenant Org Switching Gets Complicated
A common B2B pattern is a single user belonging to multiple organizations (an agency managing several client accounts, a consultant working across multiple customer orgs) with the ability to switch context between them without re-authenticating. Cognito's User Pool model ties a user identity to the pool itself, and while custom attributes and groups can represent organization membership, building clean org-switching UX — where the active tenant context flows through to authorization decisions at the API layer — typically requires a custom claims/token enrichment layer on top of Cognito rather than something it provides natively.
// Pre-token generation Lambda trigger enriching Cognito tokens with tenant context
exports.handler = async (event) => {
const userId = event.request.userAttributes.sub;
const orgs = await getUserOrganizations(userId);
const activeOrgId = event.request.clientMetadata?.requestedOrgId || orgs[0].id;
event.response = {
claimsOverrideDetails: {
claimsToAddOrOverride: {
"custom:active_org_id": activeOrgId,
"custom:org_role": await getRoleInOrg(userId, activeOrgId),
},
},
};
return event;
};
This pattern — using Cognito's Lambda triggers to enrich tokens with tenant-scoped claims — usually gets teams most of the way there without abandoning Cognito entirely.
SCIM Provisioning for Enterprise Customers
Larger B2B customers increasingly expect SCIM support so their own IdP can automatically provision and deprovision user accounts in your product as part of their own identity lifecycle management. Cognito doesn't natively expose a SCIM server; supporting this typically means building a SCIM 2.0-compliant API layer in front of Cognito that translates SCIM requests into Cognito's Admin API calls — a real integration project, but one that extends Cognito rather than requiring you to abandon it.
When Custom Auth Actually Makes Sense
Teams that move away from Cognito entirely tend to do so when the tenant/permission model is unusually complex (deeply nested organizational hierarchies with inherited permissions, dynamic per-resource ACLs that don't map cleanly onto Cognito groups or custom attributes) or when they need auth behavior Cognito's token/session model genuinely can't express without heavy workarounds. This is a smaller set of cases than it might seem — most B2B SaaS multi-tenancy and SCIM requirements are solvable as extensions on top of Cognito, and building fully custom auth means taking on session security, token handling, and credential storage risk that Cognito otherwise absorbs.
A Practical Decision Framework
- Start with Cognito unless you have a specific, already-identified requirement it can't meet.
- Extend with Lambda triggers and a thin API layer for multi-tenant context and SCIM before concluding you need full custom auth.
- Reserve custom-built auth for genuinely unusual permission models, not general "we want more control" preferences — the security surface area you take on is substantial.
This extension approach fits within our full-stack development capability, alongside multi-tenant patterns covered in multi-tenant SaaS architecture.
Discuss your project: 907-841-8407 or contact@rutagon.com.
Frequently Asked Questions
Does Cognito support SAML SSO for enterprise customers out of the box?
Yes — Cognito User Pools support SAML 2.0 and OIDC identity provider federation natively, which covers the SSO portion of most enterprise B2B requirements without custom development.
Can Cognito handle a user belonging to multiple organizations with different roles in each?
Not natively as a first-class concept, but it's achievable using custom attributes, groups, and a pre-token generation Lambda trigger that enriches tokens with the active organization context per session.
What's involved in building SCIM support on top of Cognito?
A SCIM 2.0-compliant API layer that translates standard SCIM provisioning requests (create, update, deactivate user) into corresponding Cognito Admin API calls, along with the identity mapping needed to reconcile SCIM's user model with Cognito's.
Is fully custom-built authentication ever the right choice for a B2B SaaS startup?
It's rarely the right first choice given the security risk of building session and credential handling from scratch — it's usually only justified for genuinely unusual permission models that can't be reasonably expressed as an extension on top of a managed identity provider.
How does Cognito pricing compare to building custom auth?
Cognito charges per monthly active user beyond a free tier, which is typically far cheaper than the engineering time and ongoing security maintenance cost of a custom-built auth system for most B2B SaaS user volumes.