by Format-3

Share article

{
"@graph": [
{
"@type": "Article",
"image": {
"url": "https://media.babylovegrowth.ai/blog-images/organization-13731/1793649723752_Designer-completing-a-single-sign-on-login.jpeg",
"@type": "ImageObject",
"caption": "Designer completing a single sign-on login"
},
"author": {
"url": "https://format-3.co",
"name": "Format-3",
"@type": "Organization"
},
"headline": "SSO Implementation Patterns: How to Choose and Build Well",
"publisher": {
"url": "https://format-3.co",
"name": "Format-3",
"@type": "Organization"
},
"inLanguage": "en-GB",
"description": "The main SSO implementation patterns, how SAML and OIDC differ, and how to plan, test and design sign-in so it stays secure and feels effortless.",
"dateModified": "2026-11-04T00:00:00.000Z",
"datePublished": "2026-11-04T00:00:00.000Z"
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"item": "https://format-3.co",
"name": "Format-3",
"@type": "ListItem",
"position": 1
},
{
"name": "SSO Implementation Patterns: How to Choose and Build Well",
"@type": "ListItem",
"position": 2
}
]
}
],
"@context": "https://schema.org"
}

SSO Implementation Patterns: How to Choose and Build Well

Most single sign-on projects are described as a protocol decision. They are really an architecture decision, a rollout decision and, quietly, a design decision. The patterns that matter are a small set: who starts the login (the app or the identity provider), which protocol carries the proof (SAML or OIDC), and whether something sits in the middle to translate. Get those three right and the rest is careful engineering.

This guide walks through each pattern, shows where SAML and OIDC fit, and covers the unglamorous parts that decide whether SSO works in production: testing, certificates, sessions and the sign-in screen itself.

Format-3

Build Digital Products Around Users

Format-3 brings strategy, design, engineering, and growth together to create and scale user-centric digital products across industries.

Explore Format-3

TL;DR

• Every SSO design rests on one identity provider (IdP) vouching for a user to many service providers (SPs). The patterns differ in who initiates and who translates.
• Prefer SP-initiated flows: the app can validate the state of its own request, which reduces replay and CSRF-style risk.
• Use SAML where enterprise customers or existing SAML infrastructure demand it, and OIDC for new apps, mobile and APIs. Many products end up supporting both.
• Plan from an application inventory, pilot before rollout, test in non-production, and feed authentication events into monitoring.
• Treat the login screen as part of the security model: clear IdP choices, sensible sessions, and no single point of failure left unexamined.

Table of Contents

• The shape underneath every SSO setup
• Four SSO implementation patterns
• SAML or OIDC: choosing the protocol
• Planning, piloting, testing and monitoring
• Designing the sign-in experience
• Where SSO implementations go wrong
• Our perspective
• Bringing SSO into a product that people actually use
• FAQ
• Sources

The shape underneath every SSO setup

A useful way to read any SSO diagram is to ignore the logos and find three roles. The identity provider authenticates the person. The service provider, your application, trusts the IdP’s answer. The protocol is the envelope in which that answer travels: a SAML assertion or an OIDC token.

A practical enterprise architecture, as one implementation guide describes it, has a single IdP, many SPs, centralised policy controls, directories that cover the different user populations, and high availability. That last item is easy to skim past. Once every application depends on one door, the door’s uptime becomes everyone’s uptime.

That dependency is also the argument for SSO. When authentication policy lives in one place, you can tighten it once. The US government’s Enterprise Single Sign-On Playbook makes the point plainly: centralised SSO lets agencies consolidate authentication policy and extend phishing-resistant multi-factor authentication to applications that do not natively support modern protocols.

The rest of this article is about the choices layered on that skeleton.

Four SSO implementation patterns

1. SP-initiated login

The user arrives at your application, unauthenticated. The app redirects the browser to the IdP’s login endpoint, the user authenticates, and the IdP sends them back with proof of who they are.

This is the default we would reach for. Because the application started the conversation, it knows what it asked for. According to the Inteca guide, the SP can validate the request and response state and so better mitigate replay and CSRF-like risks. An unsolicited response, by contrast, arrives with nothing to check it against.

2. IdP-initiated login

The user starts in a portal or app launcher run by the IdP and clicks a tile. The IdP posts an assertion to your application without any prior request from it.

People love this one because it matches how employees think: “I open my dashboard and my tools are there.” It is a legitimate pattern and often required by enterprise buyers. If you support it, do so knowingly, since the app has no request state to validate. A common compromise is to let the tile point to your app’s own SP-initiated entry, so the dashboard feels the same while the flow stays safer.

3. Protocol mediation through the IdP

Your application may speak one protocol while a customer’s directory speaks another. IdPs can perform protocol mediation, letting an app use OIDC while connecting to SAML-based enterprise IdPs. The app has one integration to maintain, and the translation layer absorbs the variety.

This is the adapter idea that engineers meet early in their careers. If you want a refresher on the underlying design pattern fundamentals, the same logic applies: isolate the thing that varies behind a stable interface.

4. Centralised SSO in front of legacy apps

Some applications will never learn SAML or OIDC. The pattern here is to place a centralised SSO layer in front of them so that policy, including phishing-resistant MFA, is enforced upstream. The IDManagement playbook frames this as extending modern authentication to applications that cannot support it natively. It is rarely elegant, but it brings the old estate under the same rules as the new.

SAML or OIDC: choosing the protocol

The question readers type most often is some form of “SAML vs OIDC”, and the honest answer is that it depends on where your users and your infrastructure already live.

SAML 2.0 is an XML-based enterprise standard. OIDC is a JSON-based alternative built on OAuth 2.0. One practical guide suggests SAML when integrating with enterprise IdPs or existing SAML infrastructure, and OIDC for new applications, including mobile apps and APIs.

NIST takes a similarly pragmatic line in its guidance on federation parameters: protocol selection is mostly about what the target environment supports, and OIDC’s OAuth 2.0 foundation also enables delegated access to APIs. In the US public sector, CISA recommends open standards-based protocols, including OIDC or OAuth 2.0, as agencies modernise identity services.

Question: Format | SAML 2.0: XML assertions | OIDC: JSON tokens on OAuth 2.0

Question: Natural home | SAML 2.0: Enterprise IdPs, existing SAML estates | OIDC: New web apps, mobile apps, APIs

Question: Key handling | SAML 2.0: Certificates, often rotated by hand | OIDC: Keys published and rotated through JWKS

Question: Delegated API access | SAML 2.0: Not its purpose | OIDC: Built into the OAuth 2.0 foundation

Question: Typical buyer signal | SAML 2.0: “Our IT team requires SAML” | OIDC: “We want it to work in the mobile app”

The certificate row deserves a second look. A recent comparison notes that manual certificate rotation is a common SAML operational issue, while OIDC keys rotate automatically through JWKS. That is not a reason to avoid SAML. It is a reason to put certificate expiry on a calendar and an alert before the first enterprise customer goes live.

Microsoft’s decision guide concludes that both protocols are secure and that organisations should support both when their customers span legacy enterprise and cloud-native environments. For a B2B product, that is usually where you land: OIDC first for your own roadmap, SAML because a buyer’s procurement checklist says so.

Planning, piloting, testing and monitoring

The best SSO rollouts feel boring. That is the result of a plan that starts well before any code.

Start with an inventory, not a vendor

The IDManagement playbook begins with a thorough inventory of applications, user communities and protocol readiness, then an architecture review that connects user data and security monitoring tools. You will find that a third of your apps are easy, a third need mediation, and a third need the legacy treatment described above. Knowing the split early shapes budget and sequence.

Pilot, roll out, optimise

Integration works best as a phased cycle: a pilot with a friendly group, a wider rollout, then optimisation. Pick pilot users who will tell you what hurts, such as the support team or an internal product group, rather than those who will quietly work around problems.

Test where mistakes are cheap

Testing belongs in non-production environments, checking assertion integrity and user provisioning. One implementation blueprint recommends mocking IdP responses to test your authentication logic, then using real, popular IdPs to confirm compatibility. The mock tells you your code is right. The real IdP tells you the world agrees.

Watch the events afterwards

Ongoing monitoring means connecting authentication events to your SIEM or continuous diagnostics tooling, per the playbook. Failed logins, expired tokens and latency spikes are the early signals. A rise in failures the week a customer rotates a certificate is a story you want to read in a dashboard rather than in a support ticket.

Designing the sign-in experience

SSO is sold as a convenience, and it only delivers if the screen in front of the user is legible. The Scalekit blueprint suggests displaying IdP options on the login page and offering “remember me” for returning users, with token validation done server-side.

Three design questions are worth asking before you ship:

1. How does a user know which door to use? If a company has SSO, can they type an email and be routed to the right IdP, or must they hunt for a button?
2. What happens when SSO fails? An error that says “assertion invalid” is a dead end. A message that names the next step is not.
3. Where does the session end? Convenience and exposure are the same dial. NIST notes that IdP and relying-party sessions are managed independently, so your application decides whether reauthentication requirements have been met even if the IdP session is still alive.

We have written before about why frictionless design is overrated. The relevant lesson here: remove friction that carries no meaning, keep the friction that protects people, and be deliberate about which is which.

Where SSO implementations go wrong

Most incidents are not exotic. They sit in the gap between what a protocol permits and what an implementation checks.

Trusting the XML too much. The OWASP SAML cheat sheet observes that SAML security gaps often come from implementation weaknesses, such as failing to validate message integrity or trusting insecure XML elements. To prevent XML Signature Wrapping attacks, OWASP advises using local, trusted schema copies and ignoring KeyInfo elements when validating signatures.

Setting the assurance bar by guesswork. NIST’s Federation Assurance Level scale runs from FAL1 to FAL3. FAL1 is described as a solid basis appropriate for the vast majority of use cases, requiring assertions that are signed, time-limited and audience-restricted. If your assertions do not meet that floor, fix that before debating protocol fashion.

Forgetting the single point of failure. CISA warns that SSO can create one, and advises limiting session lengths and asking software vendors for evidence of SSO best practices. It also observes that cloud-based identity services benefit from rapid, centralised patching by the provider. Plan for IdP outages with a documented break-glass path for administrators.

Letting certificates expire. Covered above, and still the most preventable outage on the list.

Our perspective

Most SSO conversations begin with the wrong noun. Teams ask “which protocol?” when the better question is “what are we asking a person to go through, and why?”

Bringing SSO into a product that people actually use

If you are adding SSO to a SaaS platform, a healthcare application or a media product, the protocol work is the smaller half of the job. Our team handles digital product discovery, design sprints and full-stack development as a single engagement, so the sign-in experience, the integration and the rollout plan are designed together. If SSO is one piece of a broader product rebuild, that is the right place to start the conversation.

FAQ

Is SAML or OIDC better for SSO?

Neither wins universally. SAML is the usual choice when you integrate with enterprise IdPs or an existing SAML estate, and OIDC suits new applications, mobile apps and APIs. Because both are considered secure, many B2B products support both and let an IdP mediate where needed.

What is the safest SSO flow to implement?

SP-initiated flows are generally preferable because the application can validate request and response state, which helps against replay and CSRF-like attacks. Whatever flow you use, require signed, time-limited, audience-restricted assertions and validate them server-side.

How do you test an SSO integration?

Test in non-production environments. Mock IdP responses to exercise your authentication logic, then connect to real, widely used IdPs to confirm compatibility, and verify assertion integrity and provisioning. After launch, monitor authentication events for failed logins, token expiry and latency.

How should single sign-on affect the login experience?

Show users clear IdP options, route them sensibly from their email, and offer “remember me” for returning users while keeping session lengths deliberate. Write error messages that name the next step, since SSO failures are where trust is won or lost.

Sources

• Enterprise SSO: Single Sign-On Implementation Guide
• Enterprise Single Sign-On Playbook, IDManagement.gov
• What is Single Sign-On (SSO) and How Does it Work?
• What is OpenID vs SAML?
• How to Implement Single Sign-On with SAML and OIDC
• Choosing Security Parameters, NIST SP 800-63C
• Secure Cloud Business Applications, CISA
• SAML versus OpenID Connect decision guide, Microsoft Learn
• SAML vs OIDC: Which SSO Protocol for Enterprise Apps
• SSO Implementation Blueprint
• Session Management, NIST SP 800-63B-4
• SAML Security Cheat Sheet, OWASP
• Design pattern fundamentals

By Format-3

Press & Media

More thoughts

Thought leadership creates value, builds knowledge and takes a stand, bridging the gap between traditional and digital platforms