DEV Community: The Scalekit Team

A SAML Security Vulnerability Handbook for Developers

The Scalekit Team — Fri, 02 Aug 2024 09:56:44 +0000

One surefire way to get stuck in developer purgatory is developing a custom implementation of the Security Assertion Markup Language (SAML) protocol to enable enterprise single sign-on (SSO) authentication… without knowing exactly what you’re getting into.

Even if you’ve read our primer on SAML implementation, you still need to fully understand the scope of possible SAML vulnerabilities and the intricate requirements of developing proper and reliable resolutions. To give you a sense of that scope, let’s examine the common vulnerabilities you need to be aware of—not as a checklist that will declare your implementation ready to handle the stringent requirements of enterprise SSO, but as a peek into how many developer hours go into a secure SAML implementation.

What makes SAML open to vulnerabilities?

As an open standard for exchanging authentication and authorization information between IdPs and SPs, SAML is not inherently vulnerable—it’s merely a description of the handshake between your B2B SaaS product (Service Provider or SP) and the Identity Provider (IdP).

Still, the default SAML response, which is both unsigned and unencrypted, is an extraordinarily complex document:

<?xml version="1.0"?>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="..." Version="2.0" IssueInstant="2024-04-15T01:01:48Z" Destination="https://app.your-saas.com/?login" InResponseTo="...">
  <saml:Issuer>https://idp-example.com/metadata</saml:Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="..." Version="2.0" IssueInstant="2024-04-15T01:01:48Z">
    <saml:Issuer>https://idp-example.com/metadata</saml:Issuer>
    <saml:Subject>
      <saml:NameID SPNameQualifier="https://your-saas.com/metadata" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">...</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData NotOnOrAfter="2024-05-15T09:01:48Z" Recipient="https://app.your-saas.com/" InResponseTo="..."/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2024-04-15T01:01:18Z" NotOnOrAfter="2024-01-18T06:21:48Z">
      <saml:AudienceRestriction>
        <saml:Audience>https://your-saas.com/metadata</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2024-04-15T01:01:48Z" SessionNotOnOrAfter="2024-05-15T09:01:48Z" SessionIndex="...">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">bob</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">bob@example.com</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">users</saml:AttributeValue>
        <saml:AttributeValue xsi:type="xs:string">admin</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

As a developer, your first task—implementing an authentication system that can properly construct and parse assertions like the above SAML content—is easier said than done.

SAML is based on XML, which has no semantics or defined structure, making it difficult to write and harder to read at a glance. You’ll want to rely on parsers and helper libraries to do the heavy lifting, but there are hundreds of implementations covering all popular programming languages. Some might be wildly popular and seem vetted by the open-source community, but you have no guarantee they’ll work as expected. They could easily introduce new unexpected vulnerabilities into your authentication infrastructure.

Your second task is establishing a security baseline in your SAML implementation by enforcing signed and encrypted assertions, using an XML Signature (XMLDSig) and SHA-256 encryption, respectively. For your authentication system to exchange signed and encrypted messages, you’re dealing now with the infrastructure required to decrypt assertions using keys and safely store certificates, which goes far beyond most developers’ know-how.

These measures help protect your users’ data, but change the contents of your SAML responses and assertions dramatically:

<?xml version="1.0"?>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="..." Version="2.0" IssueInstant="2024-04-15T01:01:48Z" Destination="https://app.your-saas.com/?login" InResponseTo="...">
  <saml:Issuer>https://idp-example.com/metadata</saml:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
      <ds:Reference URI="#pfxd32edc4b-4995-439f-ac61-a3eb7142995a">
        <ds:Transforms>
          <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        </ds:Transforms>
        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
        <ds:DigestValue>0ZGpsHSqaCe2HHtvXVuEyLWgCa0=</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>...</ds:SignatureValue>
    <ds:KeyInfo>
      <ds:X509Data>
          <ds:X509Certificate>...</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
  </ds:Signature>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:EncryptedAssertion>
    <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Type="http://www.w3.org/2001/04/xmlenc#Element">
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
      <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
        <xenc:EncryptedKey>
          <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
          <xenc:CipherData>
            <xenc:CipherValue>...</xenc:CipherValue>
          </xenc:CipherData>
        </xenc:EncryptedKey>
      </dsig:KeyInfo>
      <xenc:CipherData>
        <xenc:CipherValue>...</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </saml:EncryptedAssertion>
</samlp:Response>

Think of these SAML snippets, and the language as a whole, like a recipe. They give you all the ingredients you need to implement secure authentication, and detail which steps your system must take at each phase of the SSO process… but if you mess up even one small detail, there’s no one to blame but yourself.

The most common SAML security vulnerabilities

An exhaustive exploration of all possible SAML vulnerabilities and viable remedies could take weeks, but if you’re just getting started with validation solutions and deciding whether to build or buy, here are 10 vulnerabilities you need to investigate.

We haven’t ordered these based on any definitions of severity, complexity, or ease of remediation. Why? Because when you’re dealing with enterprise-grade authentication, even the “smallest” vulnerability hurts your trust, costs you customers, and exposes their confidential information to attackers.

XML signature wrapping (XSW)

What is it? Attackers can use XSW to inject forged elements into a SAML assertion while not affecting the validity of the signature. For example, every SAML assertion contains an attribute relating to a user’s privileges within your SaaS, like user, editor, and admin. Using an XSW attack, an attacker could change a user’s privileges from user to admin, giving them widespread access to read or download confidential data from one of your customers.
How do you prevent it? At a minimum, you need to validate the schema of SAML assertions using local, trusted copies and verify all signatures with a trusted certificate. You should also validate user input for unexpected values.

Lateral movements from non-intended responses

What is it? An improper SAML implementation might validate an assertion signed with a shared private signing key. After being authenticated once for SSO, the attacker could then move across all SaaS apps integrated into your IdP.
How do you prevent it? Validate whether the SAML response is intended for your app and discard any mismatches using zero-trust or least-privilege methodology.

Eavesdropping, theft, and man-in-the-middle attacks

What is it? SAML messages often contain details about the user and their attributes, similar to the XSW vulnerability and an admin account. An attacker capable of accessing these attributes of user accounts gains valuable information about the logic behind your authentication system and narrows their targets for social engineering attacks directly against users with the most privileges.
How do you prevent it? Ensure your SAML implementation sends all assertions over HTTPS at a minimum. You should also extend your protection with strong encryption like AES-256 with the Algorithm attribute like so:

<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>

Expired messages

What is it? If an attacker intercepts or steals a SAML message, they can exploit that later to impersonate a real user. If your SAML implementation doesn’t expire assertions after a specific time, you’ve given your attacker far more time to fine-tune and perfect their strategy for exploiting your authentication system or your users’ data.
How do you prevent it? Use the NotBefore and NotOnOrAfter attributes available from the SAML standard to create a timeline in which your SAML implementation will validate assertions. Given some leeway for clock skew, any messages outside the window must be rejected.

Open redirects

What is it? For the best user experience, most authentication mechanisms redirect users directly into the SaaS after they successfully log in. When you’re working with enterprise-grade SSO, you can use the RelayState attribute in SAML to specify the redirect URL. If an attacker learns how your SAML implementation processes redirects using query strings, they can inject a new URL to redirect users toward a phishing site.
How do you prevent it? Create an allowlist of trusted URLs in your SAML implementation to redirect users after they complete authentication for the best balance of user experience and user security. Always validate whether the SAML assertion’s RelayState attribute contains one of these hardcoded URLs.

Round-trip attacks in vulnerable XML parsers

What is it? When your SAML implementation parses and serializes an assertion multiple times during the required handshakes between the user, IdP, and SP, bugs in XML parsers can introduce bugs that change the assertion’s shape. Attackers can use stolen or forged assertions to explore your authentication system for the presence of buggy XML parsers. With that information, they can craft specific strings to bypass your authentication system and log in as a real user.
How do you prevent it? Use only well-known and recently updated open-source libraries for parsing XML. Run npm audit, or a similar command for your language/framework, to find vulnerable versions of SAML libraries you use in production.

Signature exclusion

What is it? Poorly-designed SAML implementations can entirely skip signature validation, or check only the signature in the first assertion of many. Attackers can use forged and unsigned documents to bypass those insufficient checks and access your users’ data.
How do you prevent it? Only allow SAML responses that are fully signed, and validate that every assertion in the SAML exchange is signed.

Replay attacks

What is it? These are like a distributed denial of service (DDoS) attack but targeting authentication providers, taking down your authentication services or dramatically spending what you spend on authentication requests.
- How do you prevent it? Implement HTTPs in all your requests and responses and never expose the SAML response to the browser.

XML External Entity (XXE)

What is it? SAML assertions can reference external entities through a Document Type Definition (DTD). An improperly configured XML parser would access the external entity and execute its payload, putting your authentication system at risk of a DDoS attack or attackers access to confidential information.

<!DOCTYPE Response [<!ENTITY attack SYSTEM "http://example.com/attack-payload.xml">]>
<samlp:Response ...>...</saml2p:Response>

How do you prevent it? Disallow your XML parser from fetching and processing DTDs and enforce Content Security Policy (CSP) headers on all SAML requests. Implement monitoring for filesystem reads or unexpected network requests.

Certificate faking

What is it? Attackers can use self-signed certificates with their SAML assertions to help them figure out whether a SP verifies that a trusted IdP signs your SAML. Certificate faking is not an attack itself but reveals opportunities for attackers to perform one of the above attacks more knowledgeably.
How do you prevent it? Ensure your implementation only validates SAML messages signed by a trusted IdP.

How do you identify SAML security vulnerabilities?

Part of the problem with developing an in-house SAML implementation is that you’re not only diving deep into an extraordinarily complex protocol and parser ecosystem but also constantly weighing security versus user experience. Automatically redirecting authenticated users into your SaaS is a positive and now-expected user experience, but implementing it as a developer is non-trivial.

Every nicety and feature you deliver to your SaaS users has downstream effects that could dramatically increase the horizon in which you can develop, secure, and deploy your SAML implementation.

You must still decide whether to build or buy your path toward enterprise-ready authentication with SAML. That starts with estimating the developer hours you’d need and weighing that against the all-in cost of going with an existing provider—and the time you’d win back by not doing it yourself.

If you’re going to build your own SAML implementation:

Start by understanding all the vulnerabilities and preventative measures listed above, but recognize that these are just a small subset of the possible SAML vulnerabilities and SSO security measures you should be concerned about. Stay on top of the latest security research from OASIS Open and OWASP regarding newly discovered vulnerabilities.

First off, do not attempt to write your own XML parser. XML and SAML have been around for decades, and security researchers are still discovering and fixing new exploits in popular parsers—you won’t be able to build a more secure implementation without tens of thousands of hours at extraordinary cost.

During your development work, use only modern and updated SAML/XML libraries, and beware when implementing backward compatibility with older XML parsers, which may introduce vulnerabilities you thought you’d solved. To actively test your implementation, use dynamic application security testing (DAST) tools, a SAML-specific tool like SAML Raider, or webapps like Mock SAML.

Your concerns then go beyond pure development work. After deployment, you should also implement a complimentary observability platform for real-time insights into the volume and nature of your SAML requests. To help your DevOps/SecOps/IT administration peers, you should also implement error handling and logging—they’ll need this valuable information in a user-friendly environment to troubleshoot issues and catch incidents before they become outages.

Finally, consider the ongoing maintenance cost—not just of keeping your SSO service functioning but also of regularly auditing your IdP and SP configurations for SAML best practices.

If you’re buying a SAML implementation:

You’ll be in luck with a product like Scalekit, which uses SAML for enterprise-ready SSO authentication. Instead of wading through vulnerability scans and maintaining a massively complex security posture, you can leverage all the expertise and constant improvement of a dedicated team focused solely on building the most secure B2B authentication.

Without upfront development and maintenance costs, you can achieve your goal of providing seamless authentication for your users in a fraction of the time—time you could spend far more profitably building a product your users can’t help but log in to again and again.

‍

The Strategic Role of Authentication in B2B SaaS Applications

The Scalekit Team — Tue, 09 Jul 2024 10:57:48 +0000

At the heart of a secure application design, whether it be a B2B or B2C, lies a set of core authentication features. These foundational capabilities include – stringent password policies, effective session management, and the convenience of social login options through Facebook, Google, and others. These features provide a dual function: enhancing user experience by offering familiar login methods while simultaneously upholding security measures to protect sensitive data and user identities.

In the realm of B2B SaaS applications, Authentication is the silent guardian that ensures trust and reliability in every workflow and transaction. Often overshadowed by the more visible elements, Authentication is the linchpin that quietly powers secure exchanges in the backdrop of business operations.

B2B Authentication Landscape: What Sets it Apart?

B2B environments present a unique set of challenges for authentication systems, distinct from the individual user-focused B2C applications. B2B applications must navigate layered organizational structures (each with its own hierarchy) and necessitate tailored access controls for a diverse array of stakeholders.

B2B authentication involves complex needs such as - varying auth methods for different user types (such as employees, consultants, customers), enhanced login methods (such as SSO, multi-factor authentication, Passwordless auth), seamless separation of data and settings among organizations (multi-tenancy), data security requirements, integrations with external systems, custom workflows, access logs, and many more.

Compliance requirements, specific to B2B applications, impose additional layers of complexity. Regulatory frameworks such as GDPR, SOC 2 Type II, and industry-specific standards mandate stringent data protection measures, compelling B2B businesses to implement robust authentication protocols to safeguard sensitive information.

Beyond passwords and social logins: a Paradigm Shift in B2B Authentication

Lets dive deep into the key elements of authentication that are crucial for the sustained growth and success of B2B applications - especially when catering to enterprise customer segments.

*Enhanced Authentication methods *

In the evaluation of B2B SaaS applications, enterprise customers place a premium on the authentication capabilities that align with their security requirements and operational complexities. Among these capabilities:

Single Sign-On (SSO) allows users to access multiple applications with a single set of credentials, streamlining the user experience while maintaining high security standards.
Multi-Factor Authentication (MFA) adds another layer of security by requiring users to provide two or more verification factors to gain access, significantly reducing the risk of unauthorized access.
Furthermore, the emerging trend of Passwordless Authentication, which utilizes biometrics, security tokens, or SMS codes, is gaining traction for its ability to offer an enhanced security posture alongside a frictionless user experience.

These methods collectively cater to the diverse needs of enterprise environments, ensuring both ease of use and the fortification of security measures, which are paramount in today's B2B business operations.

*Admin Portal *

B2B application admins and IT teams within enterprise organizations need a comprehensive admin portal (specialized interface) to configure and manage authentication settings. Through this admin portal, IT admins can:

Seamlessly set up Single Sign-On (SSO) integrations
Configure Directory Synchronization to ensure alignment with their internal user databases (aka active directories)

This admin portal serves as a centralized control panel, enabling the customization of authentication methods and the enforcement of security policies in tune with the unique needs of the enterprise.

*Customization *

Enterprise organizations often have diverse customization needs to align their authentication systems with their operational and branding requirements.

Firstly, there is a significant emphasis on customizing the User Experience (UX) to reflect the organization's brand identity and themes. This customization extends to user interfaces, including the login boxes, admin portals, and even the content of authentication-related emails sent to users, ensuring a consistent brand experience across all touch-points.
Secondly, the customization of authentication methods and workflows is critical; for example, some enterprises may require that all users authenticate via Single Sign-On (SSO) to streamline access and enhance security.
Lastly, there is a need to configure events and integrate authentication workflows with external systems, such as Customer Relationship Management (CRM) platforms or Observability applications.

Together, these customization capabilities allow enterprise organizations to tailor their authentication systems, reinforcing security while providing a branded and user-friendly experience.

Multi-tenancy and Org-first approach are core to B2B Authentication

Each enterprise organization would have varying Authentication methods, IT policies, and security settings for their users to access business applications. For a B2B application to support organization-specific auth methods and policies, the data architecture needs to be built with organization-first paradigm.

Additionally, customer organizations would like to restrict data and settings access to their respective admins and users. B2B applications need to support multi-tenancy for Authentication and User Management - thus ensuring seamless separation of policies, settings, and data among different organizations. Multi-tenancy in Authentication allows B2B applications to quickly onboard and manage hundreds of new customer organizations and restrict access to auth-related data such as org metadata, user profiles, passwords, session info

The organization-first data modeling and multi-tenancy together form the core of B2B Authentication needs. While general-purpose solutions may offer basic user authentication capabilities, they fall short in meeting the complex needs of B2B Authentication, particularly in terms of scalability, customization, and efficiency.

Scalability: enables businesses to scale authentication systems effortlessly as they grow and evolve. By centralizing user management and access controls, organizations can adapt authentication policies and workflows to accommodate changing needs and requirements.
Customize Auth policies: offers greater flexibility and customization options, allowing businesses to tailor authentication processes to their unique requirements. From user roles and permissions to authentication methods and workflows, organizations have the freedom to design authentication systems that align with their specific needs and preferences.
Efficiency: By centralizing authentication processes and policies, this approach reduces complexity and administrative overhead, streamlining operations and enhancing efficiency. This centralized approach also facilitates better visibility and control over authentication activities, enabling organizations to monitor and manage access more effectively.

Deliver Enterprise Authentication: navigating your options

If you’re looking to make your Authentication enterprise-ready, here are your available options:

*Build in-house *

Building these Authentication capabilities internally gives your engineering team complete control of the codebase and the ability to fully customize these features. However, it comes with several major business risks:

Distracts your product & engineering teams: Developing these capabilities internally diverts your team’s focus and impacts your core product innovation.
Increases time-to-market and cost: Building these capabilities takes several quarters as well as a dedicated team of platform engineers.
Deals slip away: Enterprise customers simply won’t wait for your SaaS product to catch up to the expectations they have around Authentication capabilities.

This option can be effective if you’ve secured a significant foothold in your market, face minimal threats from the competition, and manage a large engineering function with dedicated teams for developing platform capabilities.

*Leverage open source frameworks *

Open-source libraries enable your team to quickly launch the first version of these capabilities and test the waters. Since open-source is free, there’s no need to worry about additional software or subscription costs.

However, your team will need to learn the open-source architecture in order to build upon it and still be responsible for debugging, creating portals, maintaining security posture, hosting and managing infrastructure, scaling Auth and User management, and other upgrades.

Time to market seems quicker with open-source. However, they’re not built for specific, complex B2B needs. Your engineering team will need to understand their architecture, dig into their codebase, and customize them to fit your unique Auth needs and user management workflows. This defeats the purpose of using open-source tools in the first place.

*Use a B2B-first authentication provider *

Transitioning into the growth stage, SaaS companies face the dual challenge of strengthening their core product and expanding to the enterprise segment. Regardless of where your company is in its growth journey, developing these enterprise capabilities internally diverts your engineering team’s focus and impacts your core product’s innovation.

In the last few years, modern platforms have given engineering teams the flexibility and freedom to focus on their core SaaS product and not be burdened by the overhead of building additional capabilities. Many engineering teams today use purpose-built products such as Twilio for communications API, Sendgrid for email API, and Sentry for app monitoring.

Similarly, B2B SaaS companies would benefit from third-party products that offer enterprise capabilities such as authentication, user management, authorization, audit logs, feature flagging, and more. For example, a SaaS-first authentication platform would:

Significantly reduce your time-to-market with pre-built authentication and user management components
Solve enterprise use cases such as single sign-on, admin portals for config, pre-built login box, customization options, CRM integrations, and analytics tools
Reduce the burden on your product and engineering team by allowing them to focus on building your core SaaS product

While your team will still need to spend some time learning a new tool, you’ll benefit from a multitude of pre-built capabilities, reduced engineering costs, and more peace of mind with built-in security and integrations.

Consider quickly implementing enterprise features with an external product that’s prebuilt for B2B Auth, User Management needs. While your team will still need to spend some time learning a new tool, you’ll benefit from faster time-to-market, pre-built authentication capabilities, customer portals, reduced engineering costs, and more peace of mind with security and integrations taken care of.

Conclusion

It is time to reevaluate your Authentication strategy within your B2B SaaS application. The build vs. buy question is not only a technical decision but also a strategic imperative that can shape your growth into the enterprise segment.

The fact remains that using a third-party product built for SaaS products accelerates your time-to-market and allows your engineering team to focus on your core product with minimal resources.

We encourage you to engage in meaningful discussions and explore your authentication strategies. Challenge conventional wisdom and explore innovative approaches to authentication that address the unique needs and challenges of B2B interactions. Consider how adopting an organization-first approach or leveraging specialized authentication solutions can enhance security, scalability, and user experience.

Build vs. Buy: How to approach SSO for your SaaS app

The Scalekit Team — Tue, 09 Jul 2024 10:45:24 +0000

Every B2B organization developing new applications faces a pivotal decision: whether to build their Authentication systems from scratch or leverage a ready-to-use solution. This decision affects not only the infrastructure of your SaaS app but also the user experience, security, and scalability. One of the first Authentication requirements companies encounter is Single Sign-On (SSO). This blog explores the pros and cons of building vs. buying Enterprise-grade SSO solutions, helping you navigate this complex decision.

What is Single Sign-On (SSO)?

In today's digital landscape, managing access to numerous applications securely and efficiently is a formidable challenge for any large organization. Enterprise-grade Single Sign-On (SSO) solutions are crafted to meet this challenge head-on. These systems provide a robust, scalable, and secure authentication framework that allows users to access multiple applications with a single set of credentials.

Not only are SSO solutions tailored to handle the complex security demands of large enterprises and to integrate seamlessly with existing corporate infrastructures, but they also play a crucial role in enhancing user experience by reducing password fatigue.

The Case for Rolling Your Own Auth

Control and Customization
Without a doubt rolling your own SSO solution offers complete control over the Authentication process, allowing for customization that precisely fits your organization's specific needs. This is particularly important for unique or highly specialized use cases, where a custom SSO implementation might be the best approach.
Integration with Legacy Systems
For organizations with complex, legacy systems, a custom-built SSO might be necessary to ensure seamless integration that might not be possible with off-the-shelf solutions.
Long-term Cost Benefits
For large organizations with multiple product offerings, the initial high investment in rolling your own custom SSO might pay off over time. Depending on the size of your organization and the number of users, the cost of licensing third-party SSO solutions can be substantial depending on the vendor. Further, owning your infrastructure reduces dependency on a specific vendor’s technology, pricing changes, and terms of service. This can provide greater business continuity and stability.

The Case for Buying

Rapid Deployment and Expertise
Leveraging an SSO-as-a-service solution can significantly accelerate your time to market in two key ways: firstly, by enabling you to serve larger customers more swiftly, and secondly, by helping you launch new products more quickly. These solutions are typically ready for integration and are supported by professionals with deep expertise in authentication. Shipping SSO can be achieved within hours through just a few lines of code, rather than weeks. This efficiency stems from the complexity of building and implementing SSO, which requires understanding various protocols like SAML and OAuth, which are non-trivial. These protocols, along with other configuration needs like Identity Providers (IdPs), can distract your technical team from focusing on core products and services, unlike custom SSO implementations which require significant resources.
Cost-Effectiveness
While building Enterprise-grade SSO in-house might seem like a one-time cost, the long-term expenses of maintenance, updates, and security must be factored in. SSO-as-a-service solutions come with a subscription model that scales with your usage, offering predictability in expenses upfront costs and can dramatically reduce time spent on maintenance of a custom build. The costs associated with maintaining a custom SSO implementation can add up over time, making buying a more attractive option for some businesses.
Security
SSO-as-a-service solutions generally offer robust security measures that are continuously updated to respond to ongoing and emerging threats. This is critical in maintaining the integrity of your security infrastructure and protecting user data. Roll your own SSO and any errors in implementation can lead to vulnerabilities, potentially exposing user data and risking your organization's reputation. With a custom SSO implementation, the responsibility of staying updated with the latest security measures falls entirely on your team.
Ongoing Support and Compliance
SSO-as-a-service providers often comply with the latest regulations and standards, reducing your team's legal and compliance burdens. They also provide ongoing support and enhancements, which can be crucial for maintaining system stability and adding new features - helping you focus more on your product, and less on infrastructure. Custom SSO implementations, while offering flexibility, also require your team to stay on top of regulatory changes and support requirements.

A Faster Way to Build SSO

When developing a B2B SaaS application, Single Sign-On (SSO) inevitably becomes a requirement for every customer. However, finding a solution that offers few compromises is challenging. You need a system that’s flexible, customizable, scalabile, and most importantly secure. That's where Scalekit comes in. Our Customer Identity and Access Management platform is specifically designed for B2B SaaS, streamlining Enterprise Authentication requirements, like SSO. With Scalekit your team can concentrate on building your core product and serving more customers, without the complexities of a custom SSO implementation.

Designing B2B Authentication Experiences: Universal vs. Organization-Specific Login

The Scalekit Team — Tue, 09 Jul 2024 10:40:49 +0000

One of the first decisions you must make when architecting a new B2B application? How you’re going to allow users to authenticate.

You have two choices: the universal login page or the organization-specific login page. We’ll make the distinction clear in a moment, but for now, know that the path you choose here has significant downstream effects on the entire lifecycle of your B2B application, and in ways far more significant than designing and developing a login page that looks good. Notably, three personas are most affected with the choice you make:

Your internal product engineers, who build your application.
Your customers’ IT administrators, who provision users, manage privileges, and enable single sign-on (SSO) integration with their identity providers (IdPs) such as Okta, Microsoft Azure AD.
Your product’s users, who will be logging into your application.

Conveniently, two popular applications—Notion and Slack—have made opposite choices for end-user authentication flows. Their ubiquity makes them ideal for identifying how they implemented differing flows, tracing the pros and cons for each affected persona, and ultimately helping you create the best authentication paradigm for your application.
What are the Notion and Slack styles of Authentication?

Before diving too deeply into authentication nuances, let’s clarify our definitions.

Notion-style authentication flow uses universal login page
Slack-style authentication flow uses organization-specific login page

How are they different?

With a universal login page, the application identifies which organization the end user belongs to. In contrast, with an organization-specific page, the end user shares the organization as input to the application before they can be authenticated.

With Notion, you start authentication by loading the universal login page at notion.so/login. You give your work email address, which Notion uses to identify which organization you belong to based on the domain name. If your email is celina@foocorp.com, Notion assumes you’re part of the organization associated with foocorp.com.

Designing B2B Authentication Experiences: Universal vs. Organization-Specific Login

The Scalekit Team — Tue, 09 Jul 2024 10:35:04 +0000

One of the first decisions you must make when architecting a new B2B application? How you’re going to allow users to authenticate.

Your internal product engineers, who build your application.
Your customers’ IT administrators, who provision users, manage privileges, and enable single sign-on (SSO) integration with their identity providers (IdPs) such as Okta, Microsoft Azure AD.
Your product’s users, who will be logging into your application.

What are the Notion and Slack styles of Authentication?

Before diving too deeply into authentication nuances, let’s clarify our definitions.

Notion-style authentication flow uses universal login page
Slack-style authentication flow uses organization-specific login page

How are they different?

Notion uses that information to provide you with the next best step for the authentication flow, which might be entering a password, using SSO, receiving a magic link, or any auth setting configured by your IT admin.

In the case of Slack’s authentication experience, as an end user, you must navigate to the Slack’s organization-specific login page at a specific URL, like foocorp.slack.com. In this case, you’ve already specified which organization you belong to (Foocorp) through the subdomain, and Slack uses that information to show you the appropriate authentication flow.

In both cases, once the application identifies the end-user’s organization, it honors their authentication settings, including SSO, identity provider, multi-factor authentication (MFA), password policy, and so on.

The user experience (UX) around honoring those settings can still vary between applications. Notion’s universal login page, for example, separates the email and password fields so it can perform the home realm discovery (that’s discovering the tenant) and honor auth settings.

Note that, Dropbox hides the password field if the email address entered matches a tenant with enterprise authentication enabled.

Freshworks takes yet another approach, using home realm discovery to ascertain your tenant and redirecting your browser to an organization-specific login page.

Again, these differences might seem small, but the impact is outsized by a few orders of magnitude by the resulting choices around implementation and infrastructure.

Contributing technical factors: tenancy and home realm discovery

Tenancy is the architectural decision to isolate the authentication policies, settings, users, and data between each organization registered with an application. Multi-tenant architecture is an essential ingredient for the authentication and security of a SaaS app, ensuring a user of organization Foorcorp can never read data belonging to organization Barcorp.

Home realm discovery (HRD) is the process by which a application identifies which tenant a user belongs to from the login page. Because every application uses a multi-tenant architecture, HRD is also necessary, as there could be a hundred Celina users, each belonging to a different organization and stored inside a different tenant. HRD requires an identifier, which applications collect in a few standard ways:

The domain name (foocorp.com) on the end-user’s work email.
An organization-specific “username,” like Foocorp.
A user-specific ID that cannot be repeated elsewhere, like celina0001 versus celina0002.

If we map this idea to the universal and organization-specific login pages concept from before, we can clarify our definitions even more.

With a universal login page, the application must complete some type of HRD to authenticate end users.
With an organization-specific login page, the HRD is done as the user inputs the organization name as part of the authentication process.

Once the application completes HRD and maps the end user’s identifier to a tenant, it can honor those authentication settings and allow them to finish logging in using approved methods. Now that you understand the two possible authentication flows for a application, and how each works alongside your required multi-tenant architecture, we can explore those big implications.

For your app’s internal engineering team

Universal Login

Pros

Universal login pages are easy to design and develop, as only one possible user interface (UI) and common UX pattern exists.
You can extend universal login pages to allow a single user to log in to multiple workspaces for cross-organization collaboration similar to Notion.

Cons

Your team must implement a robust Home Realm Discovery (HRD) to discover the appropriate tenant that a user belongs to based on the user input. This Home Realm Discovery can either based on user’s email address of explicit input of user’s tenant information like Account Name, Organization ID etc. This requires additional engineering effort for the HRD implementation.
If your customers require data residency, you must engineer more network-level workarounds to redirect users to the appropriate tenant and region.

Organization-specific Login

Pros

Users perform HRD on your behalf by supplying the subdomain, which simplifies your backend logic.
In some ways, it’s easier for your team to manage data residency, as you can map the DNS records for a specific tenant (foocorp.com) to cloud resources in their region of choice.

Cons

Instead of designing and developing a single authentication flow, your team is now responsible for many.
Must develop additional measures to help new users remember the URL for their login page, such as email reminders. You may even want to create a method for them to recover a “lost” organization.

For your customer’s IT administrator

Universal login

Pros

Similar to the development process, they only have a single authentication flow and login page to worry about.

Cons

IT administrators at enterprise organizations might require far more customization than a universal login page can offer.

Organization-specific login

Pros

Customize the login page so their users perceive the product as a white-labeled solution.
Restrict authentication methods to only an approved subset of the available options, simplifying the UX and moving users toward the “best” option.
Add custom terms or disclaimer notices onto the login page for legal or compliance purposes.

Cons

Must educate their employees or customers to visit the specific URL to access the application.

For your application’s end user

Universal login

Pros

The UX is extremely straightforward: they navigate to a well-known URL like notion.so/login or through a big Log in button on your homepage.

Cons

None.

Organization-specific login

Pros

The UX around approved authentication methods

Cons

End users must remember the URL for their organization-specific login page. If they can’t remember or retrieve the information, they could be frustrated enough to create a new account or abandon your application altogether.

How do you choose between a universal vs. organization-specific login page?

Frankly, there is no direct answer. The best solution is based on your customers and admins experience in your application. As you’re making other architectural and technical decisions, such as which JavaScript UI framework to choose, whether to build a monolith or many microservices, or which cloud provider gives you the most startup credits, you should take time to weigh the user experience for each persona in light of your long-term go-to-market (GTM) strategy.

Generally, if you’re appealing to the end-user experience, universal login pages are most familiar to the widest range of users. If you need to offer the customer IT administrator complete flexibility, or are selling to enterprise customers who expect a completely white-labeled solution, then organization-specific pages are a great fit.

What type of login page did Scalekit pick? When we reach general availability, we’ll use a universal login page, where our application performs HRD using the user’s work email as the identifier.

We opted for the universal login page to ensure our users always have the simplest possible experience logging in. We don’t want situations where users have lost their accounts simply because they forgot which subdomain they’re supposed to navigate to. We know that comes at a higher technical cost to us around HRD, but it’s a sacrifice we’re willing to make for the most seamless end-user experience.

The other decision you must make early on is how you’ll build the authentication integration itself. You can go it alone and build a SAML implementation for ultimate control at the cost of complexity and many developer hours, or you can partner with a platform like Scalekit to get your B2B application enterprise-ready in days, not weeks or months.

Either way, ensure your choice lets you also pick the login page that works best for your customers—once you’ve started developing and deploying infrastructure, you can’t take your choice back.