Single sign-on & SCIM

OIDC and SAML sign-in, break-glass accounts, SCIM provisioning and push groups.

Let people sign in to IdPVault with your identity provider instead of an IdPVault password. Available on Business and MSP licenses. Everything below is configured in Administration > System settings > Single sign-on.

Single sign-on is about how people sign in to IdPVault itself. It is completely separate from the tenants IdPVault backs up - connecting Okta as your sign-in provider does not connect it as a tenant, and vice versa.

Modes

• Off - password sign-in only. No SSO button appears.
• Optional - the sign-in page shows both the SSO button and the password form. Use this while you are testing.
• Required - password sign-in is switched off. Only break-glass admins and external users can still use a password (see below).

Saving a mode other than Off requires a complete configuration; IdPVault tells you which field is missing rather than saving something that cannot work. Use Test connection before switching anyone over.

OpenID Connect

The recommended protocol - every major provider supports it. You need three things from your provider's application/integration:

• Issuer URL - IdPVault reads the rest (authorization, token and JWKS endpoints) from the provider's discovery document at <issuer>/.well-known/openid-configuration.
• Client ID and Client secret - create a confidential/web application at your provider. The secret is encrypted at rest; leave the field blank when saving to keep the stored one.
• Redirect URI - IdPVault shows it, read-only. Paste it into your provider's application exactly as shown.

The flow is authorization code with PKCE and a nonce. Set your Public URL on the General section first - the redirect URI is derived from it, and providers reject a mismatch.

SAML 2.0

Pick SAML 2.0 in the Protocol dropdown and the fields change to match. Paste your provider's IdP metadata URL and save: IdPVault reads the entity ID, the sign-in endpoint and the signing certificate from that document and stores them. Your provider's SP metadata URL is shown read-only - import it at the provider, or copy the entity ID and ACS URL by hand.

SP-initiated sign-in only: start at the IdPVault sign-in page, not from a provider dashboard tile. Responses must be signed, are matched to the request that started them, and are read only from the signature-verified part of the document.

Certificate rotation: when your provider rotates its signing certificate, open System settings and save the SSO section again. IdPVault re-reads the metadata URL and picks up the new certificate. Run Test connection to confirm.

Accounts and roles

People are matched to IdPVault accounts by email address, case-insensitively. Someone who signs in through your provider and has no account yet gets one created at first sign-in with the default role for new SSO users. Their first and last name come from your provider and refresh at every sign-in.

Accounts created this way sign in with SSO only - they never have a password, in any mode. New accounts from a provider are never placed inside an MSP client organization, and provider-driven role mapping only ever grants the global administrator or user roles. Client organization roles are always assigned inside IdPVault.

Break-glass accounts

Setting SSO to Required means nobody can sign in if your identity provider is unreachable - unless you have a way back in. That is what a break-glass account is: an administrator whose password sign-in keeps working even when SSO is required.

• Flag it on the App users page (Make break-glass), or tick the box when creating an administrator.
• Only an administrator can be break-glass, and the account must have MFA enabled - a password-only emergency door is not one IdPVault will accept.
• Break-glass sign-ins are recorded in the audit log as auth.breakglass_login, separate from ordinary sign-ins, so using the emergency door is visible.

IdPVault will not let you switch SSO to Required until at least one active administrator is flagged break-glass and has MFA on. Once required, it will not let you take that away either: disabling, deleting, demoting, clearing the flag on, or resetting MFA for the last such account is refused, and your directory cannot deactivate it over SCIM. Keep two if you can - then either one can be maintained.

External (client) users

Some people who use IdPVault are not in your directory at all - typically an MSP's client contacts. Tick Client user (external) on their account and they keep password sign-in when SSO is Required. Org-scoped roles (org admin, org viewer) are external automatically, since those people are by definition not your staff.

SCIM provisioning

SCIM 2.0 lets your provider create, update and deactivate IdPVault accounts automatically, and works with either sign-in protocol. Generate a bearer token in the SCIM provisioning section, paste it and the SCIM base URL into your provider, and enable it.

• The token is shown once, at generation. Store it in your provider immediately; IdPVault keeps only a hash of it.
• Deprovisioning disables, it never deletes. Removing someone in your directory disables their IdPVault account so the audit trail survives.
• Groups your provider pushes appear under Push Groups. Names and membership are owned by your directory and are read-only in IdPVault; what you control here is which role each group maps to.
• A person gets the highest role they are mapped to across their groups, re-evaluated whenever their membership changes. Leaving every mapped group returns them to the default role for SSO users.
• Only groups inside your provider's SCIM scope arrive here - exclude application-assignment groups you do not want to see.

Role mapping will not demote the last active administrator and never changes a break-glass account, and provisioning will not deactivate the last active administrator. Every skipped change is written to the audit log with its reason, so a mapping that did not take effect is never silent.

Troubleshooting

• The provider rejects the redirect URI. Set Public URL in System settings > General to the address people actually use, then re-copy the redirect URI - it is derived from that value.
• SAML sign-in fails after a while. The provider probably rotated its signing certificate. Re-save the SSO section to re-read the metadata.
• Someone gets a second account. Their provider email does not match the email on their IdPVault account. Matching is on email, so fix the email on the IdPVault account before their first SSO sign-in.
• Locked out with SSO required. Sign in with a break-glass admin's password and MFA, then set the mode back to Optional.