What Is SSO? Single Sign-On Explained

SSO stands for single sign-on. It is a login model where a user signs in once through a trusted identity provider, then accesses multiple applications without managing a separate password for every application.

For example, a company may use Microsoft Entra ID, Okta, Google Workspace, Ping Identity, OneLogin, or another identity provider as the central login system. Employees sign in there, complete any required MFA challenge, and then access SaaS tools, internal dashboards, infrastructure consoles, and support systems through that central identity.

SSO is not only a convenience feature. For infrastructure teams, it is an access-control and auditability control: one place to enforce login policy, disable users, require MFA, review sessions, and monitor suspicious sign-ins.

How SSO Works

A typical SSO flow has three parties:

The flow usually looks like this:

1. The user opens an application.
2. The application sees that the user is not signed in.
3. The application redirects the user to the identity provider.
4. The identity provider verifies the user with password, MFA, device policy, risk checks, or other controls.
5. The identity provider sends a signed assertion or token back to the application.
6. The application validates that assertion or token.
7. The application creates a local session for the user.

The application does not need to store the user's primary password. It trusts the identity provider's signed response.

What SSO Solves

SSO addresses several common identity problems:

• Users do not need separate passwords for every application.
• Security teams can enforce login policy centrally.
• MFA can be required from one identity layer.
• Offboarding can disable access across many applications quickly.
• Audit logs can show authentication events across the organization.
• Conditional access policies can account for device, network, location, and risk.
• Applications can avoid building complex password-management workflows themselves.

For small teams, SSO may be mostly convenience. For larger teams, regulated organizations, and infrastructure operators, SSO becomes part of operational risk management.

SSO vs MFA

SSO and MFA solve different problems.

SSO centralizes login. MFA strengthens the proof during login.

Use both where possible. SSO without MFA still leaves users exposed if a password is stolen. MFA without SSO still leaves teams managing user lifecycle, password policy, and access review across many separate applications.

SSO vs Password Managers

Password managers and SSO are complementary.

A password manager stores and fills credentials for many sites. It helps users create unique passwords and avoid reuse.

SSO removes the need for many separate application passwords by delegating authentication to a central identity provider.

In practice, teams often use both:

• SSO for applications that support federation.
• A password manager for applications that still require local credentials.
• MFA or hardware keys on the identity provider and high-risk direct logins.

SAML, OIDC, and OAuth

SSO discussions often mention SAML, OIDC, and OAuth. They are related, but not identical.

SAML and OIDC can both power SSO login. OAuth is often involved in authorization flows, but OAuth alone does not necessarily prove who the user is. OIDC adds the identity layer that applications need for login.

SAML SSO

SAML SSO is common in enterprise SaaS.

In a SAML flow:

1. The service provider sends the user to the identity provider.
2. The identity provider authenticates the user.
3. The identity provider returns a signed SAML assertion.
4. The service provider validates the signature and attributes.
5. The user gets an application session.

SAML assertions can include attributes such as email, name, groups, and role mappings. Misconfigured attributes can accidentally grant too much access, so SAML setup should be tested carefully.

OIDC SSO

OIDC uses JSON Web Tokens and OAuth-style flows. It is common for modern SaaS, developer tools, web apps, and mobile applications.

In an OIDC flow:

1. The application redirects the user to the identity provider.
2. The user authenticates.
3. The identity provider returns an authorization code.
4. The application exchanges the code for tokens.
5. The application validates the ID token and creates a session.

OIDC tends to fit modern application stacks naturally, but token validation, redirect URI configuration, and client-secret handling still need care.

Why SSO Matters for Infrastructure Accounts

Infrastructure accounts are high-value targets. DNS, cloud, CI/CD, monitoring, incident-management, and payment systems can all affect production availability.

For DNS provider accounts specifically, an attacker who gets access may be able to:

• Change A, AAAA, or CNAME records and redirect traffic.
• Change MX records and intercept email routing.
• Change TXT records, SPF, DKIM, or DMARC data.
• Remove or break DNSSEC-related records.
• Create API keys for later access.
• Delete zones or records and cause outages.

That is why SSO belongs beside other controls: MFA, multi-user access control, scoped API keys, audit logs, registrar locks, and DNSSEC.

SSO and Team Access

SSO handles the login identity. It does not automatically decide what the user can do after they sign in.

Applications still need authorization controls:

• Account roles such as admin or member.
• Zone-level access for DNS platforms.
• Read-only vs write access where supported.
• API-key scopes.
• Audit logs for who changed what.
• Offboarding workflows that remove sessions and keys.

In DNScale, multi-user accounts and zone access control cover role and zone-level permissions. Conceptually, SSO would sit above that as a centralized login layer; permissions still need to be enforced inside the application.

SSO and API Keys

SSO usually authenticates humans in a browser. API keys authenticate automation.

Do not assume SSO protects API keys automatically. If an API key is already created and stored in CI/CD, Terraform, DNSControl, or another automation system, it may continue working until it is rotated or revoked.

Good practice:

• Create dedicated users or service accounts for automation where the product model supports it.
• Scope API keys to the minimum required permissions.
• Store keys in a secrets manager.
• Rotate keys when team members leave.
• Monitor API-key creation and usage.
• Revoke unused keys.

See the API authentication documentation for DNScale API-key mechanics.

SSO Benefits

These benefits are strongest when SSO is paired with MFA, least privilege, lifecycle automation, and regular access reviews.

SSO Risks

SSO also introduces concentration risk.

SSO is not a magic security upgrade by itself. It centralizes identity, which makes good identity operations more powerful and bad identity operations more dangerous.

SSO Implementation Checklist

Use this checklist when evaluating SSO for production infrastructure tools:

1. Choose the identity provider that is already authoritative for your organization.
2. Require MFA at the identity provider, preferably phishing-resistant MFA for administrators.
3. Decide whether SAML or OIDC is the right integration path.
4. Map identity-provider groups to application roles carefully.
5. Keep at least two tested break-glass admin accounts.
6. Document how offboarding revokes application sessions and API keys.
7. Review whether local password login remains enabled.
8. Test login from normal user, admin, and disabled-user scenarios.
9. Confirm audit logs show successful and failed sign-ins.
10. Review access quarterly for high-risk tools.

For DNS and infrastructure tools, also review scoped API keys, zone access, activity logs, and registrar access controls.

Common Misconceptions

"SSO means users cannot be phished"

Not by itself. SSO centralizes login, but users can still be phished if the identity provider allows password-only login or weak MFA. WebAuthn/FIDO2 security keys provide much stronger phishing resistance.

"SSO replaces MFA"

No. SSO and MFA should work together. SSO routes authentication through one place; MFA strengthens that authentication.

"SSO controls every API key"

Usually no. Existing API keys, service accounts, and automation credentials need their own lifecycle controls.

"SSO ID means the same thing everywhere"

No. Some portals call a login identifier an SSO ID. In identity architecture, SSO means the broader single sign-on model, not one specific government, school, or service-provider account number.

Key Takeaways

• SSO means single sign-on: one trusted identity provider authenticates users for many applications.
• SAML and OIDC are the two common protocols used for SSO login.
• SSO centralizes login policy, offboarding, MFA enforcement, and auditability.
• SSO does not replace MFA, role-based access control, scoped API keys, or audit logs.
• DNS-provider accounts are high-value targets, so identity controls matter alongside DNSSEC, registrar locks, and API-key governance.

Related Guides

• Multi-factor authentication guide
• Multi-user accounts and zone access control
• DNS security best practices
• DNS hijacking
• DNScale infrastructure and EU operations
• API authentication
• Users API
• Invitations API