Single Sign-On (SSO)

Overview

Single sign-on lets your team sign in to Concord through your own identity provider instead of a Concord password. Concord speaks OpenID Connect, so any OIDC provider works, including Okta, Microsoft Entra ID, Google Workspace, Auth0, and Ping Identity. If your provider or security team requires SAML, Concord supports SAML 2.0 as well. SSO is available on the Enterprise plan, and only an Owner can set it up.

You will move through five steps: verify your email domain, create an application in your provider, configure the connection in Concord, optionally require SSO, and optionally map roles from your provider's groups.

Before you start

• You are an Owner of your Concord organization.
• You can create applications in your identity provider.
• You can add a DNS TXT record for your company's email domain.

Step 1: Verify your email domain

1. Go to Global Settings → Single sign-on.
2. Under Email Domains, add your company domain (for example acme.com). Public domains such as gmail.com cannot be used.
3. Concord shows a TXT record. Add it with your DNS provider, then click Verify once it propagates.

Add every domain your people use — a user whose email is on an unverified domain is refused.

Step 2: Create the application

In your identity provider, create a web application using the authorization code flow, set its sign-in redirect URI to the value shown in Concord's SSO settings, and copy the Issuer, Client ID, and Client secret. Follow your provider's own documentation for the exact screens.

If your provider uses SAML 2.0

Concord also federates SAML 2.0 (through AWS Cognito). Pick SAML 2.0 provider in Step 3. The named options above (Okta, Entra ID, and so on) use OpenID Connect. The SAML flow differs in a few places:

• In your provider, create a SAML 2.0 application and set its ACS / Reply URL and Audience URI / Entity ID to the two values Concord shows in the connection settings.
• Email (required): your provider must send the user's email in a SAML attribute named http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress. Concord matches users by email.
• In Concord, instead of an Issuer, Client ID, and Client secret, you provide your provider's SAML metadata URL. For role mapping, send group membership as a SAML attribute and enter that attribute's name in Concord's groups attribute field.

OpenID Connect is the simpler path and the one we recommend; use SAML 2.0 when your provider or security team requires it.

Step 3: Configure the connection

1. In Global Settings → Single sign-on → Connection, choose your provider and enter the Issuer, Client ID, and Client secret.
2. Pick the default role for new users. Limited is recommended; you can promote people afterward.
3. Click Test sign-in and complete the login. The result reports what happened, including the reason if it failed. You stay signed in as yourself throughout.
4. Click Activate. Users entering an email on a verified domain are now sent to your provider automatically.

Step 4 (optional): Require SSO

Once logins work, turn on Require SSO to block password sign-in for everyone on your verified domains. Concord requires two things first: at least one break-glass owner, and one sign-in that has already succeeded through the connection.

Once SSO is required, your provider enforces multi-factor authentication — Concord no longer challenges an authenticator app at sign-in, because your provider has already decided how people authenticate. If you rely on MFA, make sure it is required in your provider.

Break-glass owners

A break-glass owner keeps password and MFA sign-in while everyone else is sent to your provider — your way back in if the provider is ever unavailable. To qualify, someone must be an Owner with an authenticator app enrolled (set up under My profile → Security), and then have Break-glass access turned on from Global Settings → Users. Designate two, so one lost phone is not a lockout.

Step 5 (optional): Map roles from your provider

By default, every SSO user gets the connection's default role. Role Mapping reads a claim from your provider and assigns roles from it instead, re-applied on every sign-in — so removing someone from a group takes effect the next time they log in. Owner is never mappable, and while mapping is on, SSO users' roles cannot be edited in Concord.

1. Create groups for Concord (usually two are enough, one per access level — for example concord-admins and concord-limited). Concord has two mappable roles, so map by access level, not by team.
2. Have your provider send the group claim in the ID token, and confirm it arrives before configuring anything in Concord.
3. In Role Mapping, set the Claim name, add a rule per group (name to role), and choose what happens When nothing matches.
4. Save, then Test sign-in — a result naming the role confirms the rules resolve.

Launching from your provider's dashboard

Sign-in must start at Concord. Concord generates a request it recognizes on the way back, so a login launched from your provider's app tile arrives unsolicited and is rejected before Concord ever sees it.

Every active connection has a direct sign-in link, https://admin.concord.tech/sso/your-org, shown in the connection settings. Bookmark it, and make it what your dashboard tile opens:

• OpenID Connect (Okta): on the app, set General → Initiate login URI to the direct link and Login initiated by to Either Okta or App.
• SAML 2.0 (Okta): a SAML app tile always performs provider-initiated sign-on, which Concord rejects. No setting on the SAML app changes this, and Default Relay State does not help. Instead create an Okta Bookmark App whose URL is the direct link, assign it to the same people, and hide the SAML app's own tile. Keep the SAML app assigned, since it answers the sign-in request; users just should not click it directly.
• Other providers: point the dashboard tile at the direct link the same way.

How users are created

• Anyone assigned to the application who signs in gets a Concord user automatically, with the default role (unless they were invited first, in which case the invite's role wins). Each new user consumes a seat.
• Users created through SSO sign in only through your provider — they never have a Concord password, which is what makes removing them in your provider actually remove their access.
• Removing a user in your provider blocks new sign-ins immediately; an open session can remain valid for up to 12 hours.

Troubleshooting

See also User Roles & Permissions for what each mapped role can do.