What is SSO?

Single sign-on (SSO) is an authentication model in which a user logs in once with one set of credentials and gains access to every application they’re authorized for during that session, without re-entering credentials each time. Most enterprise SSO is implemented with SAML or OpenID Connect, exchanged between an identity provider and each connected service.

Key takeaways

• One login grants access to every connected application for the session.
• SAML and OpenID Connect are the two standards behind most enterprise SSO.
• An identity provider authenticates users; services trust its assertions.
• SSO flows start either at the service provider or at the identity provider.
• Versa Director, Concerto, and Titan Portal all support SAML- or OpenID-based SSO.

On this page: Why it matters · How it works · Types · SSO & Versa · FAQ

Why is SSO important?

Without SSO, users juggle a separate password for every application, which drives weak, reused, or written-down credentials – a leading cause of account-takeover breaches. SSO removes that burden: a user authenticates once against a trusted identity provider, and every connected application accepts that authentication instead of prompting again. That single control point matters for administrators too. When an employee leaves, disabling one identity-provider account revokes access everywhere at once, instead of IT tracking down dozens of logins.

Fewer passwords also means a smaller phishing surface – one credential to protect, carrying strong MFA instead of being spread thin across systems that may not support it. For organizations managing dozens of SaaS tools alongside on-premises systems like Versa Director, SSO is what makes centralized access policy possible at all.

What is SSO?

SSO works by separating authentication from the applications that need it. An identity provider (IdP) – such as Okta, Azure AD, ADFS, OneLogin, or Ping Identity – holds the user’s credentials and performs the login. When a user reaches an application (the service provider) without an active session, it redirects them to the IdP, which verifies their identity and issues a signed assertion or token confirming who they are and what roles they hold. The service provider validates that assertion and grants access without seeing the password.

Two standards carry most of this traffic. SAML is an XML-based protocol built for browser SSO, exchanging signed assertions between IdP and service provider. OpenID Connect is a newer, token-based protocol built on OAuth 2.0. Both reach the same goal – one login, many applications – through different message formats.

Types of SSO

SSO deployments vary along two dimensions: how the flow starts, and which protocol carries it. Service-provider-initiated (SP-initiated) SSO begins when a user tries to reach an application directly; it redirects them to the IdP, which authenticates them and redirects back with a login response. Identity-provider-initiated (IdP-initiated) SSO begins at the IdP’s portal – the user logs in there first, then launches an application that trusts an SSO response the IdP sends without a prior redirect. Enterprise IdPs typically support both, chosen per connector.

Independently, the protocol can be SAML-based, using signed XML assertions, or OpenID Connect-based, using OAuth 2.0 tokens. Organizations standardized on an IdP like Okta or Azure AD typically support both and choose per application.

SSO & Versa

Versa Director, Concerto, and Titan Portal each support SSO as an alternative to local username/password login. Director supports both SAML- and OpenID Connect-based SSO, tested against ADFS, Okta, OneLogin, and Ping Identity, with both SP- and IdP-initiated flows and IdP-to-Director role mapping. Concerto supports the same two protocols, tested against ADFS, Azure, Okta, and Ping Identity, with separate flows for system and tenant users. Titan Portal, Versa’s reseller portal, supports SAML-based SSO tested against ADFS, Azure AD, G-Suite, Okta, and OneLogin, admitting either any authenticated IdP user or only users already provisioned locally. SSO is enabled instead of – not alongside – two-factor authentication.

Frequently asked questions

What is the difference between SSO and multi-factor authentication?

SSO and MFA solve different problems. SSO reduces how many times a user logs in – one login reaches many applications. MFA strengthens each login with a second factor beyond a password. They’re complementary: SSO concentrates authentication at the identity provider, making it easier to enforce MFA there instead of at every application.

What is the difference between SSO and federated identity?

SSO usually means one login across an organization’s own applications. Federated identity extends that idea across separate organizations – for example, logging into a partner’s portal using your own company’s identity provider as the trust anchor. Federation is what makes cross-organization SSO possible.

What is the difference between SP-initiated and IdP-initiated SSO?

SP-initiated SSO starts when a user opens an application directly and gets redirected to the identity provider to authenticate. IdP-initiated SSO starts at the identity provider’s portal, where the user launches an already-trusted application without a prior redirect. Most enterprise IdPs support both.

Does SSO make an account riskier if the password is compromised?

It can, since one compromised identity-provider credential potentially unlocks every connected application. That’s why SSO deployments should pair with strong MFA at the identity provider – concentrating authentication into one place is only safer if that place is well protected.

Do Versa Director and Concerto support the same SSO protocols?

Yes. Both support SAML-based and OpenID Connect-based SSO, configured as a connector with IdP metadata such as certificates and endpoint URLs. Titan Portal, Versa’s separate reseller portal, supports SAML-based SSO only. All three are tested against IdPs including Okta, ADFS, Azure AD, and Ping Identity.

More on SSO

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about SSO, these are worth looking at next.