Reference Glossary
Single sign-on (SSO)
An authentication setup letting users log into a DAM with one existing corporate identity, via a protocol like SAML or OIDC, instead of a separate DAM-specific username and password.
Why it matters in a DAM
Enterprise buyers typically require SSO before rolling a DAM out company-wide because it lets IT centrally control access — instant deprovisioning the moment an employee leaves, no orphaned DAM-only password sitting around after offboarding — and removes yet another credential for users to manage and potentially reuse insecurely. SAML remains the dominant protocol behind enterprise SSO integrations with identity providers like Okta and Azure AD, while newer, mobile-oriented deployments increasingly use OIDC built on top of OAuth 2.0.
A worked example
Common mistake
Treating 'SSO support' as a single checkbox during procurement without confirming which protocol and which identity providers are actually supported — a DAM that only implements OIDC can't integrate with an organization standardized on SAML-only legacy infrastructure.
SSO lets a user authenticate once against their organization’s identity provider and carry that session into the DAM without a separate login. Under the hood, this is usually handled by one of two protocol families: SAML, which verifies identity through a signed XML assertion and remains the most widely deployed standard for enterprise SSO, or OpenID Connect (OIDC), a newer authentication layer built on top of the OAuth 2.0 authorization framework that’s better suited to mobile and modern web apps.
For a DAM specifically, SSO is less about user convenience and more about administrative control: it’s what lets an IT team revoke a departing employee’s DAM access the instant their central directory account is disabled, rather than relying on someone remembering to separately deactivate a DAM-only login. Because SAML and OIDC aren’t interchangeable and different identity providers have different levels of support for each, confirming which protocol a DAM actually implements — and matching that against the organization’s existing identity infrastructure — matters more during evaluation than the mere presence of an ‘SSO’ feature on a spec sheet.
Frequently asked
What is single sign-on (SSO)?
SSO is an authentication method that lets a user log into a DAM using one set of corporate credentials verified by a central identity provider such as Okta, Azure AD, or Google Workspace, instead of maintaining a separate DAM-specific username and password. The DAM trusts a signed assertion or token issued by that identity provider, typically exchanged via SAML or OIDC, so a single login at the identity provider grants access without a second password to remember, reset, or leak.
Why do enterprise buyers require SSO before rolling out a DAM company-wide?
Enterprise buyers require SSO because it puts access under IT's central control rather than leaving it scattered across individual DAM accounts. When an employee is added to or removed from the identity provider, say disabled in Azure AD after termination, that change instantly propagates to DAM access, closing the account the same day instead of relying on someone to remember a separate deactivation step. It also satisfies security and compliance policies that mandate centralized authentication and audit trails for every connected system.
What's the difference between SAML and OIDC?
SAML verifies identity through a signed XML assertion and remains the most widely deployed standard for enterprise SSO; OIDC is a newer authentication layer built on OAuth 2.0, better suited to mobile and modern web apps.
What's the mistake of treating "SSO support" as a single checkbox?
"SSO support" isn't a single checkbox because the details determine whether it actually works for a given organization. A vendor may support only OIDC while the company's infrastructure is standardized on SAML, or vice versa, making integration impossible despite the checkbox being marked. Buyers also need to confirm whether SCIM is supported for automated user provisioning and deprovisioning, and whether roles and permissions inside the DAM can be mapped granularly through SSO group or attribute claims, rather than every SSO user landing in one flat access tier.
What is SCIM and how does it relate to SSO?
SCIM, System for Cross-domain Identity Management, is a protocol for automating user account provisioning and deprovisioning, and it's commonly paired with SSO rather than being part of it. SSO answers who this user is by authenticating them against the identity provider each time they log in; SCIM answers which accounts should exist and with what attributes, automatically creating a DAM account when someone joins the identity provider's directory and disabling it the moment they're removed, without an admin manually managing each account.
Is SSO mainly about user convenience?
Less about convenience and more about administrative control — it's what lets IT revoke a departing employee's DAM access the instant their central directory account is disabled, rather than relying on someone remembering a separate manual deactivation.
Sources
- SAML is an authentication and single sign-on standard that verifies identity via a signed XML assertion and remains the most widely deployed protocol for enterprise SSO; OIDC adds an authentication layer on top of the OAuth 2.0 authorization framework. checked 2026-08-07 — Cisco Duo