Set up single sign-on (SSO)
Connect Okta, Microsoft Entra ID, Google Workspace, or any SAML or OIDC provider so your people sign in to BriefCatch through your own directory.
Goal: connect your identity provider so that people in your organization sign in to BriefCatch through it. Most of the work happens in your identity provider; BriefCatch supplies the two values it needs and reads back your provider’s metadata.
Step 1: Review prerequisites
Before you start, confirm all of the following:
- Your role is admin or owner. See Roles and permissions.
- Your plan includes enterprise SSO. It is an Enterprise capability.
- At least one domain is verified. SSO discovery is built on domain proof. Until a domain is verified the SSO screen shows “Verify a domain before enabling SSO” above the form — the form itself stays usable, so treat this as the order to work in rather than a hard block. See Verified domains.
- You can administer your identity provider, or you have someone who can. You will create an application there and paste values between the two systems.
If you do not hold both sides, agree who does before starting. The configuration is not usable until values have been exchanged in both directions.
Step 2: Choose your provider
Go to Settings → Security → SSO and pick the connection type.
| Choose | When |
|---|---|
| Okta (SAML) | Your directory is Okta |
| Microsoft Entra ID | Your directory is Entra ID, formerly Azure AD |
| Google Workspace | Your directory is Google Workspace |
| Custom SAML | Any other SAML 2.0 provider |
| Generic OIDC | Any OpenID Connect provider |
The named options are presets for the same two standards underneath. If your provider is not listed, Custom SAML or Generic OIDC is the right choice, not a limitation.
Step 3: Give BriefCatch your provider’s details
A display name is required for every connection type, for example Company enterprise SSO.
Everything else depends on which provider you picked:
| Provider | What BriefCatch requires |
|---|---|
| Okta (SAML) | An identity provider metadata URL. Okta connections are metadata-only — there is no manual entry path. |
| Custom SAML | Either a metadata URL, or manual entry: Sign-in endpoint plus Signing certificate (PEM), beginning -----BEGIN CERTIFICATE-----. |
| Microsoft Entra ID | Client ID, Client secret, and the provider tenant domain. |
| Google Workspace | Client ID, Client secret, and the Google Workspace domain. |
| Generic OIDC | Client ID, Client secret, and the OIDC issuer URL. |
Two things catch people out:
- The three OIDC-family providers need client credentials. You create an application in your provider first, then bring its Client ID and secret here. Without both, the form will not save.
- The tenant domain is the directory domain, not always your email domain. An Entra tenant is
often
example.onmicrosoft.com.
Manual entry appears only under Custom SAML, as “Or configure manually (no metadata URL)”. If your provider is Okta and it does not publish metadata, use Custom SAML rather than the Okta preset.
Step 4: Give your provider BriefCatch’s details
Once saved, BriefCatch shows the values to paste into the application you create in your identity provider:
| BriefCatch shows | Your provider usually calls it |
|---|---|
| ACS URL (Single Sign-On URL) | Assertion Consumer Service URL, Reply URL, or Single Sign-On URL |
| Entity ID (Audience URI) | Audience URI, Identifier, or Entity ID |
| OIDC callback URL | Redirect URI (OIDC connections) |
| OIDC redirect URI | Redirect URI (OIDC connections) |
Create a SAML or OIDC application in your provider, paste these in, and make sure the application releases the user’s email address — it is the key BriefCatch matches on.
We deliberately do not reproduce each provider’s console steps here. Provider interfaces change on their own schedule, and following a stale screenshot is worse than following your provider’s own current documentation for creating a SAML or OIDC app.
Step 5: Run a test sign-in
Use Test sign-in on the SSO page to confirm the round trip works. This is not just advice — a passing test is required before you can enforce SSO, and BriefCatch refuses enforcement with:
Run a passing test sign-in first. Enforcement needs a passing test newer than the last configuration change.
Note the second sentence. Editing the configuration invalidates an earlier passing test, so the order is always change, then test, then enforce. If enforcement is refused after you adjusted a field, re-run the test rather than hunting for another cause.
Step 6: Decide whether to require SSO
A connection and an enforcement are two different states. The SSO page shows which one you are in with an Enforced or Not enforced badge.
| State | What it means |
|---|---|
| Connected, Not enforced | People can sign in through your provider. Other sign-in methods still work. |
| Connected, Enforced | People must sign in through your provider, and see “Your organization requires single sign-on.” |
Leaving a connection unenforced is a legitimate resting state, and it is the safer one while you are still validating. Turning enforcement off is not gated and takes effect immediately, so it is also your way out if something goes wrong.
Important notes
- Organization SSO is separate from social login. The Continue with Google and Continue with Microsoft buttons are individual social login, not your organization’s connection, even when the provider is the same company. This distinction causes most SSO confusion.
- Email is the matching key. A person whose provider account carries a different email address than their BriefCatch account is treated as a different identity.
- You can turn enforcement off again. It is a toggle, not a one-way door, and turning it off is not gated.
- SCIM depends on this. Provisioning is unavailable until a connection exists. See Set up SCIM provisioning.
Related
- Verified domains and automatic membership — the prerequisite
- Set up SCIM provisioning — the next step
- Identity troubleshooting — when sign-in fails
- Roles and permissions — who may configure this