What is SSO Software? A Practical Glossary for Singapore Buyers

Single sign-on (SSO) is a vocabulary that overlaps with MFA, IAM, IGA, PAM, and CIAM in ways that confuse procurement teams in Singapore. Vendors switch labels mid-conversation, RFPs reuse the wrong term, and what is bought is often not quite what was meant. This glossary defines the core terms a Singapore buyer should walk into a vendor meeting knowing, and maps them to PDPA, MAS TRM, and IM8 realities. The goal is not to teach identity engineering — it is to remove ambiguity from the procurement conversation.

What this glossary covers

• Single sign-on (SSO): the core definition
• Multi-factor authentication (MFA) and adaptive MFA
• Federation, SAML, OIDC, and the protocols beneath SSO
• SCIM and lifecycle automation
• Identity and access management (IAM), IGA, PAM, and CIAM — how they relate
• Workforce identity vs customer identity
• Authentication vs authorisation
• Just-in-time access and zero standing privilege
• Common Singapore procurement terms (PDPA, MAS TRM, IM8, SingPass for business)
• Common SSO procurement myths

Single sign-on (SSO): the core definition

SSO is an authentication pattern where a user signs in once to an identity provider (IdP) and gains access to multiple downstream applications without authenticating again. The IdP issues a cryptographic assertion (a SAML response or an OIDC token) that the downstream app trusts. For Singapore buyers, the practical effect is that one place — not 50 — decides who is logged in. That place becomes the choke point where MFA is enforced, where session lifetimes are set, and where leavers are blocked. SSO is not a single product feature; it is the framework that makes everything else (MFA, audit, offboarding) consistent.

Multi-factor authentication (MFA) and adaptive MFA

MFA is the authentication control that requires a user to present two or more factors before access is granted. The factors come from three categories: something you know (password), something you have (hardware key, phone with an authenticator app), and something you are (fingerprint, face). Singapore PDPA case decisions and MAS TRM guidelines treat MFA on PII-bearing systems as effectively mandatory. The IM8 directive for public sector deprecates SMS as a primary factor and pushes toward FIDO2 and push-based MFA.

Adaptive MFA — sometimes called risk-based MFA — adjusts the challenge based on signals about the login attempt. A login from a trusted device on a trusted network may proceed silently; a login from a new device or an unusual location may prompt step-up. Each major SSO platform implements this differently: Microsoft Entra ID requires P2 for Identity Protection, Okta packages it as Adaptive MFA or Identity Threat Protection, JumpCloud uses Conditional Policies. The label matters less than what signals are evaluated and how step-up is presented to the user.

Federation, SAML, OIDC, and the protocols beneath SSO

Federation is the practice of one identity domain trusting another. SSO between an enterprise and a SaaS app is a federation: the SaaS app trusts the enterprise's identity provider to authenticate users. SAML 2.0 and OpenID Connect (OIDC) are the two dominant federation protocols. SAML is the older, XML-based standard still common in enterprise SaaS; OIDC is the modern, JSON Web Token-based protocol common in newer apps and mobile contexts.

For Singapore buyers, the practical implication is that almost every modern SaaS app supports one or both protocols. The work in an SSO project is not protocol design — it is configuring each app correctly: where the identity provider's metadata lives, which attributes are mapped (email, group membership, manager), and what happens if a user signs in for the first time. SCIM (covered next) handles the lifecycle complement to federation.

SCIM and lifecycle automation

System for Cross-domain Identity Management (SCIM) is the protocol that automates user account create, update, and delete operations between the IdP and downstream SaaS apps. While SAML or OIDC handles authentication, SCIM handles identity provisioning. For Singapore buyers, SCIM is what makes the offboarding promise real: when an HRIS event flows through the IdP to the SaaS apps, SCIM is the messenger that says 'this user has left, deactivate them.'

Not every SaaS app supports SCIM. The Singapore long tail of HR, accounting, and locally built apps often does not. Where SCIM is absent, the alternatives are scripted provisioning, vendor-led custom integration, or accepting manual de-provisioning with documented compensating controls. Singapore buyers should confirm SCIM support for the top 20 apps in their catalogue before signing.

Identity and access management (IAM), IGA, PAM, and CIAM — how they relate

Identity and access management (IAM) is the umbrella discipline covering user identity, authentication, authorisation, and lifecycle. SSO is one capability within IAM — arguably the most visible one to end users. The other major capabilities are identity governance and administration (IGA), privileged access management (PAM), and customer identity and access management (CIAM).

IGA covers entitlement reviews, access certification, and segregation of duties. For Singapore buyers under MAS TRM scrutiny, IGA is the layer that produces evidence for quarterly access reviews. Okta Identity Governance, Microsoft Entra ID Governance, and SailPoint are the common platforms. PAM covers privileged accounts: vaulted credentials, session recording, and just-in-time access for administrators. CyberArk and BeyondTrust dominate enterprise PAM in Singapore. CIAM covers customer identity — registration, MFA for end users, consent management. Ping Identity, ForgeRock, and Okta Customer Identity Cloud are the major options. These are distinct disciplines that often share a platform but rarely share a SKU.

Workforce identity vs customer identity

Singapore buyers should always know which side of the line they are on when discussing SSO. Workforce identity is for employees, contractors, and partners — people the organisation manages. Customer identity is for end users — registered consumers, businesses buying online, citizens using a government portal. The two have very different scaling, branding, and consent requirements. CIAM platforms must handle progressive profiling, marketing consent, and brand-led login flows; workforce platforms must handle HR integration, role-based access, and admin audit. Most major SSO vendors offer both, but on different SKUs and with different reference architectures. Treating them as the same project is a common Singapore mid-market mistake — especially in fintechs that have both employees and end users.

Authentication vs authorisation

Authentication is the process of confirming a user is who they say they are. Authorisation is the process of deciding what that user is allowed to do. SSO sits firmly in the authentication camp; authorisation is handled by the downstream app's role model, the platform's policy engine (Conditional Access, Adaptive MFA, PingAccess), or a separate authorisation service. Singapore buyers often discover the distinction during proof of concept — a user who can sign in is not necessarily a user who can perform every action. Confirm during evaluation how your SSO platform passes role and group attributes to downstream apps, and how those apps consume them. Misalignment here is a frequent cause of 'SSO works but permissions are wrong' incidents.

Just-in-time access and zero standing privilege

Just-in-time (JIT) access is the practice of granting elevated permissions for a limited time, on demand, rather than holding them constantly. Zero standing privilege (ZSP) is the broader principle: no user has admin rights by default; they request them, get them temporarily, and lose them automatically. For Singapore buyers under MAS TRM, JIT and ZSP are increasingly part of how privileged access management is expected to be delivered. SSO is a component, not the whole answer — JIT typically requires a PIM or PAM tool layered with the IdP. Microsoft Entra ID Privileged Identity Management is the most common pattern in Microsoft-heavy Singapore environments; CyberArk and BeyondTrust handle the same in mixed estates.

Common Singapore procurement terms (PDPA, MAS TRM, IM8, SingPass for business)

Singapore RFPs surface a recurring vocabulary that vendors should be ready to answer. PDPA — the Personal Data Protection Act — requires unique identification, appropriate access controls, MFA on PII-bearing systems, and audit logs for breach investigations. MAS TRM is the Monetary Authority of Singapore's Technology Risk Management guidelines, covering strong customer authentication, privileged access controls, and incident reporting for regulated financial institutions. IM8 is the public-sector ICT&SS instruction manual, with explicit identity, MFA, and audit requirements.

SingPass for business (Corppass) is the national identity scheme for government interactions. While not directly an SSO product, it increasingly comes up in Singapore identity discussions for end-user verification, KYC, and as an identity proof for high-stakes MFA recovery. Confirm during procurement that your chosen SSO platform either integrates with Corppass for authorised government services or has a credible third-party broker that does.

Common SSO procurement myths

Myth one: 'If we have MFA, we do not need SSO.' Reality: MFA on each app independently still leaves fragmented offboarding and audit gaps. SSO centralises authentication so a leaver loses access in one place. Myth two: 'SSO will cover all our SaaS on day one.' Reality: 30-50 SaaS apps integrate cleanly; another 5-15 require custom work that takes weeks. Myth three: 'Entra ID Free is enough for PDPA.' Reality: Without P1 (Conditional Access) or P2 (Identity Protection), you cannot enforce risk-based or per-app MFA — both of which PDPA case decisions increasingly expect. Myth four: 'SSO is a one-time project.' Reality: SSO is a long-term operational commitment. Each new SaaS, each HRIS change, and each MFA rotation feeds back into the platform. Treat it as ongoing, not a single deal.

Explore the products

Bridging the glossary to procurement

Beyond definitions, Singapore procurement teams find two specific bridges useful in their first vendor meetings. The first is to ask vendors to map their proposed platform to the IAM, IGA, PAM, CIAM quadrant — and to identify which SKUs cover which capabilities. This stops the conversation from drifting between disciplines and makes the per-capability cost visible. The second is to ask vendors to provide a written PDPA / MAS TRM / IM8 mapping table covering data residency, MFA strength, lifecycle automation, audit retention, and DPO export formats. Vendors that can deliver these tables on request tend to integrate cleanly with Singapore audit cycles. Those that cannot, often surface friction at the DPO review stage.