Single Sign-On (OIDC)

Single sign-on lets people at your email domain sign in to CoreValue through your own identity provider (IdP) instead of a password. Your IdP decides who can sign in, applies its own multi-factor policy, and records the sign-in in its own logs.

Single sign-on is available on the Enterprise plan. It uses OpenID Connect, so it works with identity providers that support that standard, such as Okta and Microsoft Entra ID. SAML is available on request.

What you need

• An organization owner or admin to configure it. Only the owner can require it.
• An OIDC app registration at your IdP (a "web application" with the authorization code flow).
• Access to your domain's DNS, to add one TXT record.

Set it up

1. In CoreValue, open Settings → Single sign-on.
2. Enter your IdP's issuer URL, the app's client ID and client secret, and your email domain (for example example.com). Save. CoreValue reads the issuer's discovery document (/.well-known/openid-configuration) and refuses an issuer that does not match it exactly.
3. Copy the Redirect URI the page shows into your IdP app registration as the sign-in redirect URI. If your IdP asks for an initiate login URI (the app tile), use the one shown beside it.
4. Add the TXT record the page shows to your DNS: _corevalue-sso.<your domain> with the value corevalue-sso-verification=<token>. Then press Verify domain. Until the domain is verified, nobody can sign in through the provider.
5. Press Test sign-in and sign in through your IdP.

The issuer must match the iss value in the tokens your IdP issues, character for character. For Microsoft Entra ID it has the form https://login.microsoftonline.com/<tenant-id>/v2.0. For Okta it is your Okta domain, or your authorization server's URL such as https://<your-org>.okta.com/oauth2/default.

How people sign in

People choose Continue with SSO on the sign-in page and enter their work email. CoreValue sends them to your IdP and back.

• New people get a CoreValue account the first time they sign in, as a member of your organization. An owner or admin can change their role on the Members page.
• People who already have an account with the same email are linked to it, if your IdP confirms the address (the email_verified claim). If it does not, the sign-in is refused rather than linked.
• An IdP sign-in for an address outside your verified domain is refused.

Each new account also gets a personal organization, as every sign-up does; people land in yours after signing in through your IdP.

Requiring single sign-on

The owner can turn on Require single sign-on. After that, people at your domain cannot sign in, sign up or reset a password with email and password, or sign in with Google or GitHub; they must use your IdP.

• The switch cannot be turned on until the owner has signed in through your IdP at least once.
• The organization owner is never blocked, so a broken IdP cannot lock the organization out. Keep the owner's password: if the owner has none, the console shows a warning beside the switch (it does not stop you), because the owner then signs in only through your IdP, and CoreValue's operator break-glass is the way back in if the IdP is unreachable.
• If your IdP locks you out, CoreValue support can turn the requirement off. That action is recorded in our audit log and in your organization's.
• People who are already signed in stay signed in until their session expires, unless the owner ticks Also sign out members at this domain who are signed in now when turning the requirement on. Then their sessions end at once (everyone at the domain who is a member, except the owner and the person turning it on), they sign back in through your IdP, and the audit log records how many sessions ended. If that step fails, enforcement stays on and the owner is told; the owner can sign members out again at any time while the requirement is on, with Sign out members at this domain who are signed in now, which is also how to force a sign-out after an incident.
• While the requirement is on, the owner cannot be removed, demoted or leave, and ownership cannot be handed to someone at your domain who has no password. Turn the requirement off first.

Turning the requirement off restores password sign-in; nothing is deleted.

Security

• Your client secret is encrypted before it is stored, with a key held outside the database, and is never shown again after you save it.
• Every change — saving the provider, verifying the domain, turning the requirement on or off, removing it — appears in your organization's audit log. The secret never does.
• CoreValue asks your IdP for openid email profile only; it does not request offline access or refresh tokens.

What is not included yet

• SAML (available on request).
• Mapping IdP groups to CoreValue roles.
• SCIM provisioning: removing someone at your IdP does not remove them from CoreValue. Remove them on the Members page.