Single Sign-On (SSO)

How single sign-on works

1. A person opens an application and chooses to sign in with the company account.
2. The application redirects them to the identity provider.
3. The identity provider checks their identity with its own rules: password, multi-factor authentication, passkey, device checks.
4. It sends the person back with a signed statement of who they are (a SAML assertion or an OpenID Connect ID token).
5. The application verifies the signature, matches the identity to an account, and starts a session.

Role	What it does
Identity provider (IdP)	Holds the accounts and authenticates people
Service provider or relying party	The application the person wants to use
Assertion or ID token	The signed statement of identity passed between them
Directory	The list of people and groups the identity provider manages

SAML 2.0 vs OpenID Connect

Two standards carry most SSO traffic.

	SAML 2.0	OpenID Connect
Published by	OASIS, as an OASIS Standard in 2005	The OpenID Foundation (OpenID Connect Core 1.0, 2014)
Message format	XML assertions	JSON Web Tokens
Built on	Its own XML protocol	OAuth 2.0 (RFC 6749)
Typical use	Enterprise web applications, older directories	Web and mobile applications, consumer and workforce accounts
Set-up	Exchange metadata files and signing certificates	Register a client ID, a secret and a redirect URL

For the person signing in, the result is the same. Most corporate identity providers support both, and the choice depends on what the application offers.

SCIM provisioning

SSO answers one question at sign-in: who is this person? It does not create, update or remove accounts in advance. That is the job of SCIM 2.0, the System for Cross-domain Identity Management, defined in RFC 7643 and RFC 7644 (IETF, 2015). With SCIM, the identity provider pushes users and group memberships to each application, and removes them when someone leaves.

Without SCIM, applications use other methods:

• Just-in-time provisioning: an account is created the first time someone signs in with SSO, with a default role.
• Invitations or file imports for accounts created ahead of time.
• Blocked sign-in as the main offboarding control: once the corporate account is disabled, the person can no longer sign in, but their account in the application remains until someone deactivates it.

SSO in DAM and marketing work

• Offboarding. When a sales manager leaves, disabling their corporate account should end their access to unreleased product photography as well as to email.
• External users. Agencies, freelancers and distributors are rarely in the company directory. They need invitations, guest accounts, share links or a brand portal instead.
• Roles at first sign-in. With just-in-time provisioning, the default role decides what a new employee can see on day one, so it should be the most restricted useful role.
• An administrator route. If the identity provider is misconfigured or down, someone still needs a way in to fix settings.

Common mistakes: requiring SSO before everyone has signed in with it once; allowing account creation without restricting email domains, which lets personal accounts in; and assuming that SSO ends API tokens or open sessions, which depends on the application.

Single sign-on in Freedam

Freedam offers SSO with two identity providers: Google (Google Workspace and Gmail accounts) and Microsoft (Microsoft Entra ID work or school accounts, and personal Microsoft accounts). Sign-in uses OAuth 2.0 with OpenID Connect.

• Administrators switch on Google, Microsoft or both in Access Settings. The login page then shows Continue with Google or Continue with Microsoft.
• Each provider can be limited to a list of email domains. Create accounts on first sign-in (off by default) gives new accounts a role chosen per provider, and roles set per email domain take priority.
• Require single sign-on refuses password sign-in for everyone except administrators, who keep an Administrator sign-in link so a misconfigured provider cannot lock the workspace out.
• A first SSO sign-in with an email address that already has an account links the two. People can link or disconnect a Google or Microsoft account in their settings.
• Accounts can be given an end date, or deactivated after a period without sign-in that the administrator sets. Deactivation ends open sessions and deletes the account's API tokens.
• SSO is included in the Business and Tailored plans.

Details: Access Settings and Signing In in the Freedam docs, and the security page.

Frequently asked questions

What is the difference between SSO and SAML?

SSO is the result: one company account for many applications. SAML 2.0 is one of the standards used to achieve it, alongside OpenID Connect. An application can offer SSO without supporting SAML.

Does SSO replace multi-factor authentication?

No, it moves it. With SSO, the identity provider applies its own multi-factor rules at sign-in. Applications can still ask for a second factor of their own, for example for administrators or for accounts that sign in with a password.

What is SCIM provisioning?

SCIM is a standard API that lets an identity provider create, update and deactivate accounts in other applications automatically. It complements SSO: SSO handles sign-in, SCIM keeps the list of accounts in step with the directory.