TL;DR

SSO and SAML setup is often the single biggest blocker on enterprise go-live timelines. This guide gives implementation managers and onboarding teams a plain-language glossary of every term they’ll encounter, a step-by-step SSO and SAML setup checklist for clients, and a catalog of common mistakes that break authentication. If you coordinate between your product team and your client’s IT department, this is your reference document.

SSO configuration shows up on almost every enterprise onboarding plan. And almost every time, it takes longer than anyone expected.

The reason is simple: the people coordinating the setup (implementation PMs, customer success managers, onboarding coordinators) aren’t identity engineers. They’re project managers trying to keep a go-live date on track while navigating a protocol they encounter a few times a year. Meanwhile, the client’s IT team speaks in acronyms like IdP, ACS URL, and Entity ID, expecting fluency from day one.

This guide bridges that gap. It’s not a developer tutorial. It’s a practitioner’s reference for coordinating SSO and SAML setup for clients, written for the person who needs to collect the right information, ask the right questions, and avoid the mistakes that push go-live dates by weeks. If SSO setup is one milestone in your broader SaaS onboarding process checklist, this is where you zoom in on that step.

SAML SSO is not just an enterprise checkbox. As one practitioner-focused blog put it, “it is a trust boundary between your SaaS product and the customer’s identity system.” Treat it that way.

Explore GoLiveFlow’s platform to see how SSO-enabled client portals fit into structured onboarding.

Core SSO and SAML Glossary

Before you start any SSO setup conversation with a client, you need to speak the language. Below are the terms you’ll actually encounter during configuration, defined for implementation teams rather than developers.

SSO (Single Sign-On)

SSO is an experience, not a technology. It means: sign in once, access everything without logging in again. When your enterprise client says “we need SSO,” they mean their employees should be able to click into your app from their company portal without entering a separate username and password.

Why it matters during onboarding: SSO is usually a hard requirement before an enterprise client will roll out your product to their full organization. No SSO, no company-wide launch.

SAML (Security Assertion Markup Language)

SAML is the protocol that makes SSO work in most enterprise environments. It’s a standardized way to tell external applications that a user is who they say they are. Think of it as the technical plumbing underneath the SSO experience.

The key distinction: SAML is a protocol. SSO is the experience. Many teams treat them as synonyms, but they solve different problems. SAML defines how identity information gets securely exchanged. SSO is what the end user sees.

SAML 2.0

The current version of the SAML standard, ratified as an OASIS Standard in March 2005. Yes, 2005. It replaced SAML 1.1 and remains the backbone of enterprise SSO two decades later. When someone says “SAML” without a version number, they mean SAML 2.0.

IdP (Identity Provider)

The Identity Provider is the client’s system. It’s the “source of truth” that holds user credentials and confirms identity. Common examples: Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, Ping Identity, OneLogin.

Why it matters during onboarding: You need to know which IdP the client uses before you can send them the right setup instructions. Each IdP has a slightly different configuration interface.

SP (Service Provider)

The SP is your application, the one that needs to authenticate users. If you’re onboarding a client onto your SaaS product, your product is the Service Provider.

SAML Assertion

The SAML assertion is the signed message that proves a user is authenticated. After someone logs in through their IdP, the IdP sends a SAML assertion to your application containing user attributes like email, name, and role. It’s digitally signed so your app can trust it hasn’t been tampered with.

ACS URL (Assertion Consumer Service URL)

This is the endpoint on your application where the IdP sends the SAML assertion after authentication. Your ACS URL might look something like https://app.yourproduct.com/saml/acs. Get it wrong, and the assertion has nowhere to land. Nothing works.

Why it matters during onboarding: This is one of the most frequently mistyped values in the entire setup. A trailing slash, a missing “s” in https, a wrong path segment, and authentication silently fails.

Entity ID

A globally unique identifier for either the IdP or the SP. It’s typically a URL-formatted string (like https://app.yourproduct.com/saml/metadata) but doesn’t need to resolve to an actual webpage. Both sides need to agree on the exact Entity ID values.

Metadata

Metadata is the XML configuration file exchanged between the IdP and SP. It contains everything the other party needs to complete the connection: endpoint URLs, Entity IDs, certificates, supported bindings. Instead of copying and pasting individual values, some systems let you upload or link to a metadata file that populates everything automatically.

X.509 Certificate

The cryptographic certificate used to sign and sometimes encrypt SAML assertions. This is the trust anchor of the whole setup. The IdP signs assertions with its private key, and your SP uses the corresponding public certificate to verify authenticity.

Critical operational detail: These certificates expire. Typically within 1 to 3 years (Microsoft Entra ID defaults to 3 years; Google Workspace defaults to 5). When they expire without rotation, SSO breaks for every user on that connection. More on this in the post-setup checklist below.

SP-Initiated vs. IdP-Initiated SSO

Two different login flow directions. In SP-initiated SSO, the user starts at your application’s login page, which redirects them to their IdP for authentication. In IdP-initiated SSO, the user starts in their company’s identity portal (like an Okta dashboard) and clicks a tile to launch your app. SP-initiated is more common in production and generally considered more secure.

RelayState

An optional parameter that preserves where the user was trying to go before authentication kicked in. If someone clicks a deep link to a specific project page in your app, RelayState carries that URL through the authentication flow so the user lands on the right page afterward, not a generic dashboard.

Claims / Attributes

Additional user data passed inside the SAML assertion beyond just “this person is authenticated.” Common claims include email address, first name, last name, department, and role. Your application uses these to create or update user profiles. Getting the attribute names mapped correctly between the IdP and SP is one of the trickier parts of setup.

NameID

The primary identifier for the user within the SAML assertion. It’s often the user’s email address, but it could be an opaque identifier or a username depending on how the IdP is configured. The format matters: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress is different from urn:oasis:names:tc:SAML:2.0:nameid-format:persistent, and a mismatch will cause login failures.

Related Identity Terms Clients Will Raise

Enterprise clients don’t always distinguish cleanly between authentication, provisioning, and compliance. Here are the adjacent terms that come up in SSO onboarding conversations.

SCIM (System for Cross-domain Identity Management)

SCIM handles automated user provisioning and deprovisioning, while SAML handles authentication. When an enterprise customer says they need “SSO support,” they might actually mean they want both: authentication via SAML and automated user lifecycle management via SCIM. As one implementation guide noted, SAML answers “Are you really you?” while SCIM answers “Should you have access to this system?”

Why it matters during onboarding: Clarify early whether the client needs just SAML or SAML plus SCIM. These are separate integrations with different timelines. Lumping them together under “SSO” causes scope confusion.

OIDC (OpenID Connect)

An alternative to SAML that’s more common in modern web and mobile applications. OIDC uses lightweight JSON Web Tokens (JWTs) instead of XML. It’s preferred for mobile-first authentication and consumer-facing products. Some clients may have environments that use OIDC instead of (or alongside) SAML.

JIT Provisioning (Just-In-Time Provisioning)

When a user logs into your application via SSO for the first time, their account is automatically created with default roles. This saves IT administrators from manually creating accounts in advance. But there’s a catch: as practitioners at EnterpriseReady.io warn, “You should not automatically provision full accounts when a SAML user logs in because you will have no way to deprovision these accounts.” Use JIT provisioning carefully, and pair it with SCIM if the client needs automated deprovisioning.

MFA (Multi-Factor Authentication)

Multi-factor authentication is almost always enforced at the IdP level, not in your application. When a client asks about MFA for their SSO users, the answer is usually: “Your IdP handles that.” This is actually one of the security benefits of SSO, the IdP can enforce MFA policies consistently across every application.

SSO Tax

The SSO Tax refers to the practice of SaaS vendors gating SSO behind expensive enterprise pricing tiers. The term was popularized by Rob Chahin when he created the website sso.tax, which catalogs vendors that upcharge for what many consider a basic security feature. Some vendors bundle SAML SSO with unnecessary features, inflating costs by 3x to 10x or more.

This matters in client conversations. Enterprise buyers are aware of the SSO Tax and increasingly push back on it. CISA’s “Secure by Design” guidance explicitly recommended that SSO be available by default as part of base offerings, not as a premium add-on. Grip Security found that 80% of the SaaS applications employees use are not in their company’s SSO portals, partly because the cost of adding each application to SSO is prohibitive.

GoLiveFlow includes SSO/SAML at its Enterprise tier ($99/seat/month) with no minimum seats and unlimited client contacts. Check the pricing page for the full breakdown.

SOC 2

A compliance framework that frequently requires SSO controls. If your client’s security team is asking about SOC 2, they want to know that your application supports centralized authentication and that you can demonstrate proper access controls. For more on navigating these security conversations, see the security and SOC 2 buyer guide.

The Client SSO Setup Checklist (Step by Step)

This is the operational core of the article. Use it as a working checklist for every SSO and SAML setup you coordinate with clients. Each step includes the context an implementation PM needs.

For teams managing this alongside other onboarding milestones, implementation tracking software can help you keep the SSO workstream visible without losing it in a broader project plan.

Phase 1: Pre-Setup (Information Gathering)

Before anyone touches a configuration screen, you need answers to these questions from the client.

1. Confirm which IdP the client uses.
Ask directly: “Does your organization use Okta, Microsoft Entra ID, Google Workspace, Ping Identity, OneLogin, or something else?” The answer determines which setup guide you send them.

2. Identify the IT contact who will configure the IdP side.
You cannot configure the client’s IdP for them. You need a named person with admin access to their identity provider. Get their email and confirm they’re available during your setup window.

3. Determine email domain(s) to be associated with SSO.
Most implementations enforce SSO for specific email domains (e.g., everyone with an @clientcompany.com email). The client may have multiple domains (acquisitions, regional offices). Get the full list.

4. Clarify whether SCIM or automated provisioning is also needed.
This is the question most onboarding teams forget to ask upfront. If the client expects user accounts to be automatically created and removed based on their directory, that’s SCIM, not SAML. Separate the scope now, not during testing.

5. Agree on user attribute requirements.
What data should flow through the SAML assertion? At minimum: email address, first name, last name. Some implementations also need department, role, or group membership. Document these early so both sides configure their attribute mappings to match.

6. Check for existing user accounts that need migration.
If the client already has users logged in with email/password, those accounts need to be linked to the new SSO identities. As EnterpriseReady.io notes, “Your users don’t want to lose their history when their login is changed from a plain user-based login to a SAML login.” Plan the binding strategy before you configure anything.

Phase 2: Configuration Exchange

This is where the two sides swap the technical details needed to establish the trust relationship.

1. Share your SP metadata with the client’s IT contact.
Provide them with your Entity ID, ACS URL, and X.509 certificate. If your product supports a metadata URL (something like https://app.yourproduct.com/saml/metadata), share that instead, so the client’s IdP can import everything automatically.

2. Client IT creates a SAML application in their IdP.
The client’s admin creates a new “application” or “enterprise application” in their IdP (the exact terminology varies by vendor) and inputs your SP metadata. This is their work, but send clear instructions. Every major IdP has a slightly different interface.

3. Client IT shares their IdP metadata back.
You need their SSO URL (the endpoint where your app sends authentication requests), their Entity ID, and their X.509 certificate. Again, a metadata URL or XML file is the cleanest exchange method.

4. Map attributes and NameID format.
Confirm that the NameID format matches what your application expects (usually email address). Then verify that each claim/attribute name in the IdP maps to what your SP expects. If your app expects email but the IdP sends http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, the mapping will fail silently.

5. Configure group or role mapping if needed.
If your application assigns different permissions based on roles or groups, confirm how the IdP will signal those. This usually means mapping IdP groups to application roles in your SAML configuration.

Phase 3: Testing and Validation

Testing is where most SSO setups reveal their configuration errors. Budget time for this. It rarely works perfectly on the first attempt.

1. Test with a non-admin test account first.
Never test SSO with the admin account that configured it. Admin accounts often have special permissions that mask issues regular users will hit. Create or designate a standard user account for testing.

2. Keep password-based “backdoor” login active during testing.
If SSO breaks during testing (and it probably will at least once), you need a way back into the application. Do not disable password authentication until SSO is fully validated.

3. Verify both SP-initiated and IdP-initiated flows.
Test the login starting from your application’s login page (SP-initiated) and from the client’s IdP dashboard (IdP-initiated). They can fail independently.

4. Check attribute mapping with a SAML tracer.
Install a SAML tracer browser extension (available for Chrome and Firefox). It intercepts the SAML assertion in real time and shows you exactly what attributes are being sent. This is the fastest way to diagnose mapping mismatches without involving developers.

5. Test deep linking via RelayState.
Send a deep link to a specific page in your application and verify that after SSO authentication, the user lands on that page rather than the default dashboard. Broken RelayState is a common complaint from end users.

6. Validate with multiple browsers and incognito windows.
Cached sessions mask problems. Test in incognito mode to simulate a fresh login.

Phase 4: Go-Live and Post-Setup

The SSO connection works. Now make it stick.

1. Enforce SSO for the client’s domain (with a grace period).
Flip the switch to require SSO for all users on the client’s email domain, but give a grace period (typically 1 to 2 weeks) for stragglers who haven’t logged in via SSO yet. Communicate the cutoff date clearly.

2. Set certificate expiration monitoring.
This is the step everyone skips and later regrets. Microsoft Entra ID sends certificate expiration alerts at 60, 30, and 7 days before expiry. But not every IdP is that helpful. Add calendar reminders or monitoring alerts for every client’s certificate expiration date. When a certificate expires unnoticed, SSO breaks for every user on that connection.

3. Document the configuration for both sides.
Create a record of the Entity IDs, ACS URL, IdP URL, certificate thumbprints, attribute mappings, and any custom settings. Both your team and the client’s IT team should have a copy. You’ll need it when certificates rotate or team members change.

4. Establish a certificate rotation process.
Don’t just monitor expiration. Document the actual steps to rotate certificates: generate a new cert, share it with the other party, update the configuration, validate, then decommission the old cert. Activating a new certificate before the SP has it is a top cause of SSO outages.

5. Schedule quarterly SSO health checks.
Put a recurring task on the calendar. Review certificate expiration dates, check for attribute mapping changes (especially after IdP upgrades), and verify login flows still work. This turns SSO from a set-and-forget risk into a managed process.

For teams running these steps across multiple clients simultaneously, building a repeatable process matters. An onboarding playbook template can standardize the SSO setup phase alongside every other onboarding milestone.

Common SSO and SAML Setup Mistakes

Practitioners consistently report that SSO usually fails because of tiny details nobody checks. One SSOJet contributor put it bluntly: “mostly just bad copy-pasting or server clocks being weird.” Here are the mistakes that come up again and again.

Mistake	Symptom	Fix
Trailing slash mismatch in ACS URL	Authentication redirect fails with “invalid endpoint” error	Compare URLs character by character. `https://app.example.com/saml/acs` is different from `https://app.example.com/saml/acs/`
Wrong NameID format	User authenticates but app can’t match them to an account	Confirm both sides agree on the NameID format (email vs. persistent vs. transient)
Expired X.509 certificate	All SSO users suddenly can’t log in	Monitor expiration dates. Rotate certificates proactively, at least 2 weeks before expiry
Clock skew between IdP and SP	Assertion rejected as expired or “not yet valid”	Ensure both servers sync to NTP. SAML assertions have tight validity windows (often just minutes)
Audience restriction mismatch	IdP returns a valid assertion but SP rejects it	The audience field in the assertion must exactly match the SP’s Entity ID
Missing email attribute in assertion	User authenticates but app shows “email required” error	Verify the IdP is configured to send the email claim and that the attribute name matches what the SP expects
Activating new cert before SP updates	SSO breaks immediately after certificate rotation	Always share the new certificate with the SP first, update the SP config, test, then activate the new cert on the IdP
Not testing with a non-admin account	SSO appears to work in testing but fails for regular users	Always test with a standard user account that has no special IdP or SP privileges

As one practitioner blog documented, “Most SAML incidents are configuration problems disguised as authentication failures: clock skew, certificate rollover, wrong audience, open redirects, replay attacks, and tenant confusion.” When SSO breaks, check the configuration before you check the code.

Following implementation best practices for documenting decisions and maintaining communication logs helps catch these issues before they reach production.

Why SSO Setup Stalls Onboarding (and How to Prevent It)

SSO is rarely the hardest technical task in an implementation. But it’s uniquely positioned to stall everything because it sits at the intersection of two organizations. Your team controls the SP side. The client’s IT team controls the IdP side. Neither can complete the work alone.

The typical failure pattern looks like this: the implementation PM sends SP metadata to the client contact, the client contact forwards it to their IT team, the IT team has questions but emails the wrong person, a week passes, someone responds with incomplete IdP metadata, the PM enters it and testing fails because of an attribute mismatch, another week passes. Suddenly a 2-day task has consumed a month.

Prevention comes down to three things.

First, front-load the information gathering. Don’t wait until the SSO phase of onboarding to ask which IdP the client uses. Capture it during kickoff. Identify the IT contact then. The SSO and SAML setup checklist for clients should start before the SSO phase formally begins.

Second, give the client a single document with everything their IT team needs. Entity ID, ACS URL, certificate, attribute requirements, NameID format, and step-by-step instructions for their specific IdP. Reduce the back-and-forth to one exchange in each direction.

Third, set a testing meeting. Don’t rely on async testing. Schedule a 30-minute call where both sides test the connection live with a SAML tracer open. Most configuration issues can be resolved in minutes when both teams are looking at the same assertion in real time.

For teams looking to reduce time-to-value across their onboarding portfolio, getting SSO right consistently (rather than heroically each time) is one of the highest-impact improvements.

How GoLiveFlow Supports SSO-Gated Client Onboarding

When SSO is configured, the client’s users need somewhere secure to land. GoLiveFlow’s branded client portal serves as that destination, providing a step-by-step onboarding experience behind authenticated access.

GoLiveFlow supports SSO/SAML at the Enterprise tier ($99/seat/month) with no minimum seats and unlimited client contacts. The platform includes role-based access controls, encryption at rest and in transit, and SOC 2 compliance is in progress. For enterprise buyers coordinating SSO alongside dozens of other onboarding tasks, the combination of a client-facing portal, automation rules, and engagement scoring means the SSO milestone doesn’t disappear into a spreadsheet.

The SSO and SAML setup checklist for clients described in this guide maps directly to a milestone in any GoLiveFlow onboarding project. Assign tasks, track completion, set SLA-based escalations, and keep both your team and the client’s IT team moving.

Get in touch to discuss enterprise SSO onboarding.

Frequently Asked Questions

What is the difference between SSO and SAML?

SSO (Single Sign-On) is the user experience: log in once, access multiple applications. SAML is one of the protocols that makes that experience possible. SAML defines how identity data gets securely exchanged between an Identity Provider and a Service Provider. You can implement SSO using SAML, OIDC, or other protocols. They’re related but not interchangeable.

What information do I need from a client to set up SAML SSO?

At minimum: the name of their Identity Provider (Okta, Microsoft Entra ID, Google Workspace, etc.), the email domain(s) to associate with SSO, a named IT contact with IdP admin access, and their IdP metadata (SSO URL, Entity ID, X.509 certificate). You also need agreement on which user attributes (email, name, role) should be passed in the SAML assertion.

How long does SSO setup typically take during client onboarding?

If both sides are prepared and responsive, the technical configuration can be done in a day. In practice, the back-and-forth between your team and the client’s IT team stretches it to 1 to 3 weeks. Front-loading information gathering and scheduling a live testing session are the best ways to compress the timeline.

What happens when a SAML certificate expires?

SSO breaks for every user on that connection. The SP can no longer validate the signature on SAML assertions from the IdP. Users see authentication errors, and the only fix is to update the expired certificate on whichever side holds the stale copy. Microsoft Entra ID sends alerts at 60, 30, and 7 days before expiry. Not all IdPs do, so proactive monitoring is essential.

Do clients need SCIM if they already have SAML SSO?

Not necessarily, but many enterprise clients expect both. SAML handles authentication (proving who you are). SCIM handles provisioning and deprovisioning (creating and removing user accounts automatically). If the client mentions “automated user management” or “offboarding,” they need SCIM in addition to SAML. Clarify this during the pre-setup phase to avoid scope surprises.

Should I support SP-initiated SSO, IdP-initiated SSO, or both?

Support both, but prioritize SP-initiated. SP-initiated SSO is more common in production and generally more secure because the authentication request originates from a known service provider. IdP-initiated SSO is convenient for users who start from their company’s app dashboard but carries slightly higher security risk from unsolicited assertions.

What tools help debug SAML SSO issues during testing?

A SAML tracer browser extension (available for Chrome and Firefox) is the single most useful tool. It intercepts the SAML assertion as it passes through the browser and shows you the raw XML, including every attribute, the NameID, the audience, the signature, and the timestamps. Most configuration issues become obvious within seconds of reading the traced assertion.

Why does SSO often cost extra in SaaS products?

This practice is known as the “SSO Tax,” where vendors gate SAML SSO behind enterprise pricing tiers. The logic is that only enterprise buyers need SSO, so it gets bundled with premium features. Critics (and CISA’s Secure by Design guidance) argue SSO is a basic security feature that should be available by default. The result is that many organizations avoid connecting applications to their SSO portals simply because the per-app cost is too high.