SSO and SCIM

VaultTerm supports enterprise identity so an organization can let its own identity provider (IdP) own who signs in and what role they get. Two single sign-on protocols are supported, plus SCIM 2.0 for automated provisioning. All of it is per-org: a provider is configured for one organization and only ever provisions into that org.

OpenID Connect (OIDC)

The OIDC client uses discovery to read the provider’s endpoints and JWKS, then runs the Authorization Code flow with PKCE. On first login from a configured provider it does JIT provisioning: a new user is created in that provider’s org and linked to their IdP identity. An existing same-email account is linked only on a provider-verified email, never silently merged into a password account. The returned id_token is verified against the provider’s JWKS, and iss, aud, and exp are checked, so a misconfigured provider fails loudly rather than mid-flow.

SAML 2.0

The SAML path is SP-initiated and uses the HTTP-POST binding for the assertion. The service-provider entityID and Assertion Consumer Service (ACS) are served at the API origin. The implementation owns the security-critical validation — XML signature validation against the IdP certificate, signature-wrapping defence, and audience and clock checks — and normalizes a validated assertion onto the same identity claims the OIDC path uses, so JIT provisioning and role mapping are shared between the two protocols.

Mapping IdP groups to teams and roles

Both protocols can carry the user’s IdP group membership. A provider can map those groups to VaultTerm teams and roles: when a user signs in, their groups are matched against the provider’s role map and the highest-privilege matching role is applied. This works with the group claims emitted by providers such as Okta and Azure AD, so org structure in the IdP drives team membership and role in VaultTerm without per-user setup.

SCIM 2.0 provisioning

For full lifecycle management, VaultTerm exposes a SCIM 2.0 endpoint — an Enterprise capability. An IdP (for example Okta, Azure AD, or OneLogin) authenticates with a SCIM-scoped API token and can:

• Create and update users in the org.
• Deactivate users — the point of SCIM — so a departure in the IdP deprovisions the VaultTerm account.
• Sync groups to teams, keeping team membership in step with the IdP.

SCIM users sign in via SSO; they are created without a usable password. See API tokens and SCIM for issuing the token and the endpoint details.

Social login is not enterprise SSO

Social login — Apple, Google, and Microsoft — is for individual free-tier signups, not for org identity. A social login makes the person an org-of-one and is never used as an organization’s IdP; only the per-org OIDC and SAML providers above provision into an org. Keep the two distinct: social login is consumer onboarding, enterprise SSO is tenant identity.

Who can configure a provider

Provider configuration is gated by an allowlist: only emails listed in the SSO_ADMIN_EMAILS environment variable may manage SSO providers.

# comma-separated allowlist of admins permitted to configure SSO providers
[email protected],[email protected]

See Auth configuration for the surrounding auth settings.

Where to go next

• Issue a SCIM token and review the provisioning endpoints in API tokens and SCIM.
• Configure the auth environment in Auth configuration.