B2C and B2B SaaS Authentication Architectures

Reading Time: 7 minutes

In the context of both Business-to-Consumer (B2C) and Business-to-Business (B2B) SaaS, a well-architected CIAM solution will address the distinct needs for both the similarities and the differences between the two models. Where B2C services are designed for direct consumer use, B2B refers to services intended for (corporate) organisational customers, typically with a more complex structure involving multiple authentication use cases.

Each requires a varied approach to identity and access management, particularly when it comes to handling scalability, complexity, security, and the user experience. With an increasing reliance on SaaS solutions, CIAM integrations must adapt to meet a diversity of authentication needs, and in a previous article, I talked about understanding B2C vs B2B SaaS applications from the CIAM perspective. My name’s Peter Fernandez, and in this article, I’m going to explore CIAM architectures in both B2C and B2B contexts and discuss the key to creating secure and user-friendly environments that facilitate smooth interactions and protect against unauthorised access.

B2C Authentication

In a B2C architecture, the user experience is paramount because the focus is on individual consumers. Authentication solutions need to be user-friendly, yet robust enough to protect sensitive data. B2C authentication emphasises ease of use, scalability, and a wide range of user authentication methods, from basic to advanced options using predominantly the OIDC and OAuth 2.0 protocols. B2C environments typically prioritise simplicity, ease of use, and speed in the authentication processes to cater for a typically large user base.

Single Sign-On (SSO)

In a B2C context, SSO often leverages third-party Social login options like Google, Facebook, Apple, etc, and B2C applications typically connect with these Social identity providers through the use of the OpenID Connect (OIDC) or OAuth 2.0 protocols. When a user logs into a SaaS application that supports Social, the process of first-factor — and in some cases multi-factor — authentication is handled by a third-party identity provider, and once authenticated, the application grants access based on the information returned from that upstream IdP.

Whilst the use of SSO provides multiple benefits — i.e. allows a user to log into multiple applications with a single interactive authentication, allows users to sign in with different accounts (whilst at the same time providing for a single user profile no matter which account a user chooses to use), and/or mitigates costly password handling; see my article above for more details — there are a number of challenges that will typically need to be catered for:

• Dependence on Third-Party Providers: If a Social login provider experiences downtime or security breaches, it can impact users’ ability to authenticate. Having the ability to leverage more than one Social provider gives the user a choice, and by implementing Account Linking, the user experience remains consistent no matter which choice they make.
• Limited Control: SaaS developers have less control over the authentication flow and the user data maintained, so having the ability to augment via supplementary identity management gives the additional level of functionality required; see my article Architecting a CIAM Solution for further details.

Multi-factor Authentication

Multi-factor Authentication (MFA) is implemented to add an additional layer of security beyond first-factor credentials. This could include SMS-based OTP (One-Time Passcode), email OTP, Magic Link, or push notifications from an authentication app. If a system detects a higher risk (e.g., a new device or location) or requires some step-up operation, it can prompt the user to provide a second factor as described in the article below.

Whilst this provides additional security, reducing the risk of unauthorised access by requiring multiple pieces of evidence of the user’s identity, and helps users feel more secure, there can be challenges that a CIAM integration will need to overcome:

• User Friction: While MFA is more secure, it can create a friction point for users, especially if the second factor is delayed (e.g., slow delivery when using SMS). Implementing an adaptive process that allows control over the situation and/or the user communities who must go through MFA is a valuable mechanism to mitigate potential user frustration.
• Vulnerability: Some MFA architectures can be vulnerable to attack, such as SIM-swapping in SMS-based MFA scenarios or other Man-In-The-Middle (MITM) attacks associated with email and the like. So, having the flexibility to support multiple options, also allowing the user to choose with which to register, offers increased security.

Passwordless Authentication

Passwordless authentication methods eliminate the need for users to remember and enter passwords and can include methods such as magic links or biometric verification via the use of Passkeys (read the article below to discover more). When a user attempts to log in, instead of entering a password, the SaaS application uses another credential to validate a user’s authenticity; in the case of Passkeys, the rolling of first-factor authentication and MFA into one seamless operation.

This has the obvious benefit that users do not need to remember or manage passwords, and without passwords, there are fewer opportunities for password-based malicious activity, such as phishing or brute force attacks. It also alleviates the need for managing passwords and the complexity that comes with doing so, particularly if you are heading down the DIY route from a CIAM perspective.

However, passwordless authentication is not without its challenges, which a successful CIAM integration must seek to address:

• User Confusion: Users may not be familiar with passwordless methods, leading to potential confusion or abandonment. Having support to ease users into passwordless workflows by allowing progressive migration is a user experience that serves customers in a manner they feel most comfortable with.
• Resource Dependency: If the user cannot access their email, say, or doesn’t have access to the device on which their Passkey is stored, authentication can become challenging. So, fallback options — using Social or even passwords, say — reduce dependency and minimise friction.

B2B Authentication

In B2B architectures, the authentication process is often more intricate, due to the involvement of multiple users within a single organization, different levels of access, and access control requirements (et al). Whilst many of the key B2C considerations like MFA and SSO are also relevant, B2B SaaS CIAM is arguably more focused on security, the granularity of access, and integration with enterprise identity providers (optionally using the SAML protocol).

Multitenancy

Multitenancy allows a single instance of a (B2B SaaS) application to serve multiple, discrete customer communities by logically isolating data and configurations, while sharing the same underlying infrastructure. This logical isolation is often referred to using the term tenant or tenancy, where a tenant essentially provides all of the setup particular to a specific user community. From a CIAM perspective, this requires a way of associating a user with the tenant to which they are subscribed.

Tenancy, however, doesn’t necessarily mean that the users in each community are discrete (i.e. members of only a single tenant). You may have a situation where there is a need to support users who can be associated with more than one tenant — i.e. where a user is a customer subscribed to more than one tenant of a B2B SaaS application. In such cases, it’s often important to introduce the notion of a subscribed user, where certain user characteristics, such as preferences, say, are treated independently by creating aspects of a user’s profile that are common across all subscriptions, as well as aspects that are unique to a particular subscription.

Federated Identity

(Enterprise) Federation allows an organization to use its existing identity provider (IdP) to authenticate users across multiple SaaS platforms without maintaining separate user accounts for each service. In this case, a B2B organization integrates its corporate identity provider (e.g., Microsoft Active Directory, Okta, or Google Workspace; typically using protocols like SAML or OpenID Connect) with a third-party SaaS application, and when users attempt to log in, the SaaS platform redirects them to the enterprise IdP for authentication. After successful authentication, the IdP sends a SAML Assertion or OIDC ID Token back to the SaaS platform, granting access. Benefits of a federated approach include:

• Centralised User Management: Enterprises only need to manage user identities and permissions in one central location.
• Improved Security: By relying on trust relationships, organisations ensure that robust security practices (like MFA or conditional access) are applied to all connected services.

However, the federated approach doesn’t come without potential challenges:

• Integration Complexity: Integrating a B2B SaaS platform to leverage the various corporate IdPs can be a complex and time-consuming process. Systems that rely on the use of protocols like Kerberos or LDAP become much more of a challenge to address.
• Single Point of Failure: If the federated IdP is compromised or experiences downtime, users may be unable to authenticate to a connected service. Having a seamless way to route to alternatives and/or use cached credentials can

Access Control

In B2B SaaS scenarios, managing permissions is critical for ensuring that users can only access the resources they are authorised to view or modify. An access control mechanism like RBAC (Role-Based Access Control) will often integrate tightly with the authentication process, where user permissions are assigned as that user authenticates. SaaS implementations can then retrieve a user’s Role(s) from claims provided by the (federated) identity provider, which can help determine which resources or actions the user can access within the SaaS platform — thus enabling organisations to precisely control who can access specific features or data based on said user’s role. Using RBAC can also help simplify tracking and reporting for compliance with regulations (e.g., GDPR, HIPAA, etc).

However, whilst RBAC plays a useful role, it does have challenges that leveraging the likes of ABAC (Attribute-Based Access Control) and ReBAC (Relationship-Based Access Control), in addition, can solve (see the below article for more details):

• Overlapping Permissions: If roles are not carefully defined, users may receive excessive permissions or be incorrectly restricted.
• Role Management Complexity: Managing a large number of roles, especially in larger organisations, can become complex and cumbersome.

Contextual and Adaptive Authentication

Contextual or adaptive authentication dynamically adjusts the authentication requirements based on factors such as the user’s location, device, or time of access. Whilst this can also be beneficial in B2C situations, in a B2B SaaS environment, analysing contextual factors — such as login attempts from a new device or unusual geographic location — is particularly useful in determining risk levels upon which assessment for additional verification (e.g., MFA) can be made.

Benefits:

• Security and User Experience: Provides stronger authentication when risk is high, but allows users to authenticate easily under low-risk circumstances.
• Reduced Friction: Prevents unnecessary authentication challenges for users on trusted devices or in familiar locations.

Challenges:

• Risk Calculation Complexity: Accurately assessing the risk level of login attempts requires sophisticated algorithms and data analysis.
• User Confusion: Legitimate users may be blocked or delayed due to misinterpreted context, leading to frustration.

B2C to B2B Evolution and Beyond

An effective CIAM integration can pave the way for B2C applications to more readily evolve to service a B2B SaaS audience as well. For example, with the right CIAM implementation, a B2C travel-oriented application or a B2C application for (project) planning, say, can be packaged to provide service to user communities across multiple organisations.

An effective CIAM integration can also easily support the various permutations often seen in a B2B SaaS context. B2B2C — a business model where two companies collaborate to deliver SaaS solutions to the same end customer, or B2B2B, a business model where two companies collaborate to deliver SaaS solutions to another business, are just two examples of other possible B2B style opportunities that can be realised.

For more information on choosing the right CIAM approach, see the article entitled: