Single Sign-On (SSO)

In practice, an employee authenticates once against a central identity provider, such as Microsoft Entra ID, Okta, or Google Workspace, and the provider issues a signed SAML assertion or OIDC token confirming who they are. Each connected application, referred to as a service provider, trusts that signed assertion instead of maintaining and checking its own separate password for the user, and the user moves between applications without re-entering credentials as long as the underlying session remains valid. Because access to every connected app flows through this one relationship, adding or removing a user's SSO access instantly grants or revokes their reach across the entire connected application portfolio.

SSO brings clear operational benefits: employees manage far fewer passwords, which reduces the temptation to reuse them across services, and security teams gain centralized offboarding, a single action disables access everywhere at once rather than requiring IT to individually revoke dozens of separate application logins. It also lets an organization enforce one consistent multi-factor authentication policy at a single choke point rather than trying to configure and audit MFA separately across every connected tool, something increasingly relevant for regulated Indonesian enterprises consolidating large portfolios of SaaS applications under one identity provider.

The tradeoff is concentration risk: because one login now unlocks everything, the identity provider account itself becomes the single highest-value target in the organization, and a successful phishing attack or account takeover against it can cascade into every connected system at once, not just one. This makes protecting the SSO account with phishing-resistant multi-factor authentication and applying least privilege and conditional access policies at the identity provider level a priority that outranks protecting any individual downstream application on its own.