Single Sign-On and Identity Management

This section covers identity from initial provisioning to access removal. It helps a business choose federation, MFA, lifecycle automation and recovery controls without confusing successful login with complete identity governance.

Decision summary: Use this hub to plan the complete identity lifecycle rather than treating SSO as a login button.

The identity lifecycle behind the feature

For “Single Sign-On and Identity Management”, the design must cover the full identity lifecycle: invitation or provisioning, authentication, role assignment, change, recovery, suspension, deprovisioning and retained audit evidence. Confirm current provider and protocol behaviour before implementation.

How to plan single sign-on for a business app

Planning single sign-on starts with understanding who will use the application and which identity systems already exist in the business. Most UK organisations already run Microsoft Entra ID (formerly Azure AD), Google Workspace, or a similar directory. Building a separate login system when one of these is already in place creates unnecessary overhead for both users and the operations team.

The first practical step is to catalogue existing identity providers. Ask which directories the finance, HR and IT teams already manage, and whether staff are accustomed to logging into tools with their corporate credentials. If the answer is yes, the application should almost certainly consume that existing identity rather than creating its own user table.

Next, define the user roles the application needs and confirm they can be expressed through groups or attributes in the existing directory. An application might need to distinguish between administrators, standard users and read-only auditors. If those groups already exist in Entra ID or Google Workspace, the SSO integration can map them directly. If not, the directory administration will need to create them, which is a decision that belongs to the IT team rather than the application developer.

Then consider the session behaviour. How long should a user remain logged in? Should idle sessions time out? What happens if a user's account is disabled in the directory — should the application kick them out immediately, or wait until the next session check? These are not abstract questions. They affect how quickly a leaver loses access, and they need answers before a supplier writes a line of code.

Finally, document the failure modes. If the identity provider goes down, can users still reach the application through a backup method, or is access lost entirely? For internal tools that may be acceptable. For customer-facing portals, the business needs a clear position on that risk.

SSO vs separate logins: pros and cons

Separate logins give the application total control over its user table, password rules and session logic. That simplicity is appealing for a small internal tool with three users. The downside appears when the tool grows to thirty users, then three hundred, and someone leaves the company. Without SSO, an administrator must remember to disable that person's account in every separate system. Miss one, and the leaver retains access.

SSO shifts authentication to a central system the business already trusts. When someone joins, their account is created once in the directory. When they leave, disabling that single account revokes access to every connected application. For organisations above a handful of staff, this alone usually justifies the integration effort.

The trade-offs are real, however. SSO introduces a dependency on the identity provider. If the provider has an outage, every connected application is affected. SSO also requires coordination between the application team and the IT team that manages the directory, which adds a governance step to onboarding new tools. And for applications that serve external users — customers, suppliers or the public — corporate SSO is typically irrelevant, so a separate registration path is still needed.

A practical rule of thumb: if every user of the application already has an account in a corporate directory, SSO is almost always the right choice. If the user base is mixed — some internal, some external — the application will need both paths, and the planning conversation should cover how those two identity sources interact.

Integrating with Microsoft Entra ID and Google Workspace

Microsoft Entra ID and Google Workspace are common identity platforms in UK organisations. Most SSO planning starts with one or both. The integration mechanics differ, but the business planning steps are similar.

For Entra ID, the application registers as an enterprise application within the tenant. An administrator configures the redirect URLs, assigns users or groups, and maps directory attributes to claims the application can read — typically a user ID, email address, display name and group memberships. The application then trusts Entra ID as the identity source and reads those claims on each login.

For Google Workspace, the equivalent is configuring an OAuth 2.0 client in the Google Cloud Console and connecting it to the organisation's workspace domain. The claims structure is different, but the principle is the same: Google authenticates the user, the application receives a set of assertions, and it uses those to grant access and assign roles.

The practical difficulty is rarely the protocol itself. It is the mismatch between what the directory exposes and what the application expects. An application might need a department code, but the directory stores it in a custom attribute that is not sent by default. An application might expect a simple role string, but the directory provides a list of group object IDs that need translating. These mismatches are normal and should be surfaced during planning, not discovered during testing.

Ask a prospective supplier specifically how they handle attribute mapping and whether they have integrated with your chosen provider before. If they assume a standard claim set that does not match your directory structure, the integration will require custom work.

Identity provider options for UK businesses

Beyond Microsoft and Google, several identity providers serve the UK market. Okta, Auth0, Ping Identity and ForgeRock all offer enterprise-grade directories and SSO capabilities. Some UK organisations also run on-premises Active Directory with federation services, though that pattern is declining as cloud directories become the default.

The choice of provider is usually not a decision the application project makes in isolation. It is constrained by what the business already pays for and what the IT team is prepared to support. If the organisation has standardised on Entra ID, introducing Okta purely for one application creates a second directory to manage, which is the opposite of what SSO is meant to achieve.

For SaaS products sold to other businesses, the calculation is different. A SaaS founder typically needs to support whichever identity provider each customer uses, which means building against standard protocols rather than a specific product. The planning question then becomes: which protocols do we support, and how much configuration do we expose to each customer's IT administrator?

When evaluating providers for a new or expanding identity setup, check which protocols they support, how they handle group assertions, whether they offer a UK data-resident option, and what their pricing model looks like as user numbers grow. Do not assume that a provider popular with US startups will have the same enterprise features or data-handling posture required by a UK organisation subject to UK GDPR.

How to plan user provisioning and deprovisioning

Authentication handles who can log in. Provisioning handles whether their account exists in the application at all. These are separate concerns, and conflating them is a common mistake.

With SSO alone, a user who has been granted access to the application in the identity provider can log in, but the application may still need a local record for that user — to store their preferences, their assignment to specific records, or their notification settings. Creating that local record when the user first logs in is called just-in-time provisioning. It is simple to implement but gives the application no control over who gets provisioned: anyone the identity provider sends will get a local account.

SCIM (System for Cross-domain Identity Management) offers more control. It allows the identity provider to push user creation, updates and deletions to the application in real time. When a new starter is added to a group in Entra ID, a SCIM push creates their record in the application. When they are removed, SCIM deactivates or deletes the record. This is the approach most enterprise customers expect, and its absence can be a barrier to adoption for B2B SaaS products.

Deprovisioning deserves particular attention. A user who leaves the company should lose access promptly. With just-in-time provisioning, disabling their directory account stops them logging in, but their local record — and any data associated with it — remains. The business needs a policy on what happens to that data: is it reassigned, archived, or deleted? That policy sits outside the SSO implementation, but the SSO project should flag it as a decision point.

When scoping provisioning work, ask the supplier whether they support SCIM, whether they can handle group-based provisioning, and what happens to a user's data when their directory account is disabled. If the answer is vague, the deprovisioning story is probably incomplete.

Multi-factor authentication policies for business apps

Multi-factor authentication (MFA) adds a second check after the password — typically a code from an authenticator app, a push notification, or a hardware key. For business applications, MFA is increasingly expected rather than optional.

The key planning question is who controls the MFA policy. If the application uses SSO with Entra ID or Google Workspace, MFA is typically enforced at the identity provider level. The application does not see the second factor; it simply receives a claim that the user has authenticated. This is usually the cleanest approach, because it means the business sets one MFA policy that applies to all applications, and users only perform the second factor once per session.

If the application has its own user table — for example, for external users who do not have corporate accounts — MFA must be implemented within the application itself. This means choosing which factors to support, managing enrolment flows, handling lost devices and providing backup codes. Each of these is a non-trivial piece of work that should appear in the specification and the estimate.

A common mistake is enforcing MFA on every single login, which trains users to treat it as an annoyance rather than a security measure. Most identity providers allow MFA to be remembered for a configurable period or trusted on specific devices. The application's planning should specify whether it defers to the provider's MFA session settings or applies its own logic.

For applications handling sensitive data — financial records, personal data subject to UK GDPR, or access to critical infrastructure — the business should consult a security specialist to define what MFA policy is appropriate. This article does not constitute security advice, and the right policy depends on the specific risk profile of the system and the data it processes.

How to handle password policies without frustrating users

When an application relies on SSO, password policy is largely outside its control — it is set by the identity provider. But applications that maintain their own user tables, even for a subset of users, need a password policy, and getting it wrong drives support costs up and user compliance down.

The traditional approach — demanding uppercase, lowercase, numbers, symbols and a minimum length, with forced rotation every thirty days — has been widely questioned by security guidance in recent years. Users respond to complex rules by choosing predictable patterns: Password1!, Password2!, Password3!. The result is a policy that looks strict on paper but produces weak passwords in practice.

Current NCSC guidance favours usable password policies, password-manager support and checks against compromised credentials rather than arbitrary complexity and routine forced rotation. The specification should therefore follow the organisation’s current security policy and threat model, support long passphrases, and require password changes when compromise or another defined risk event justifies them.

Account lockout policies also need thought. Locking an account after five failed attempts protects against brute-force attacks but also creates a support ticket every time a user mistypes their password several times. A better approach for many business applications is to introduce increasing delays after failed attempts rather than a hard lockout, or to require MFA after a threshold of failures.

The specification should state the password policy explicitly, including minimum length, whether complexity rules apply, whether breached-password checking is used, what the lockout threshold is, and how recovery works. Leaving these as "industry standard" guarantees a disagreement at acceptance testing.

Federated identity and SAML vs OIDC explained

Federated identity means trusting an external system to vouch for a user. Instead of the application checking a password itself, it accepts a statement from a trusted identity provider that the user is who they claim to be. SSO is the most common use of federation, but the concept also covers scenarios where two organisations trust each other's directories — for example, a supplier accessing a client's portal using the supplier's own corporate login.

SAML (Security Assertion Markup Language) and OIDC (OpenID Connect) are the two protocols most often used to implement federation. They solve the same problem — passing identity information from a provider to an application — but they work differently.

SAML is an XML-based protocol that has been the enterprise standard for over a decade. It is well supported by older identity systems and by Microsoft's enterprise products. SAML exchanges are complex under the hood, involving XML signatures, assertions and redirects, but from the business perspective the important point is that SAML is mature, widely understood by IT teams, and the default choice for many corporate environments.

OIDC is a newer protocol built on top of OAuth 2.0, using JSON tokens rather than XML. It is the standard for consumer-facing applications and is increasingly adopted in enterprise contexts as well. Google Workspace uses OIDC. Many modern SaaS products default to OIDC. It is generally simpler to implement and debug than SAML, and it works more naturally with mobile applications and single-page applications.

For a business planning a new application, the practical question is not which protocol is better in the abstract. It is which protocol the organisation's identity provider supports most cleanly. If the business runs on Entra ID, both SAML and OIDC are available, but the IT team may have a preference based on their existing configuration patterns. If the application will be sold to other businesses, supporting both is often necessary, because some customers will only support SAML while others prefer OIDC.

When briefing a supplier, state which protocol or protocols are required and which identity provider the application must connect to. If the supplier proposes OIDC but the IT team only supports SAML, that mismatch will surface late and cause delays. Resolving it at the planning stage takes a single conversation.

Identity controls to verify

• Name the identity source, lifecycle owner and tested emergency-access route.
• Check current product availability and licensing directly with the chosen identity provider.
• Define the source of truth for identity, role assignment, joiners, movers and leavers.
• Confirm protocol, claim mapping, tenant boundaries, recovery access and break-glass administration.

Primary guidance checked for this edition

Sources for “Single Sign-On and Identity Management” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.

• NCSC: Multi-factor authentication for corporate services
• OpenID Connect Core specification
• OASIS SAML 2.0 technical overview