Single sign-on and SCIM

Single sign-on and SCIM solve two separate directory problems. OIDC lets the identity provider authenticate a person; SCIM lets it create and deactivate people as the company roster changes.

Both are available to a Business or Enterprise team and can be configured by an Owner or Admin.

OIDC single sign-on#

Create an OpenID Connect web application in the identity provider with this redirect URI:

https://omniio.dev/api/auth/sso/callback

Then open Team and enter the issuer URL, client ID, client secret, and one or more work-email domains. Omniio reads the authorization, token, JWKS and user-info endpoints from the issuer's discovery document and refuses setup if discovery or the configuration is invalid.

The OAuth client uses PKCE and requests only:

openid email profile

There is no offline_access request. Omniio needs an identity, email and profile for sign-in, not a refresh token for the company's directory.

Issuer

The provider's OIDC issuer URL, such as the company's Okta or Entra tenant. Changing it requires disconnecting and registering again.

Client credentials

A confidential OIDC client ID and secret created for Omniio. Treat the secret as an upstream credential and rotate it at the identity provider when required.

Email domains

Comma- or space-separated domains routed to this provider at sign-in. Domains can be updated without replacing the connection.

Names and profile images follow the identity provider on subsequent sign-ins. Omniio does not enable a setting that blindly trusts a provider's email claim as verified; that would let a misconfigured provider claim an account it does not own.

Disconnecting deletes the OIDC provider link, not the people or their team membership. Domain routing stops and members return to ordinary Omniio sign-in.

SCIM 2.0 provisioning#

Point the identity provider's SCIM integration at:

https://omniio.dev/api/auth/scim/v2

Choose Issue token, copy the bearer token immediately, and paste it into the provider. Omniio stores only its hash and cannot display the plaintext again. Issuing another token replaces the connection and invalidates the previous token immediately.

Provisioning behavior#

A person created by either first OIDC sign-in or SCIM is added to the owning team as a Member, subject to the same plan and seat checks as an invitation. An account already belonging to any team is not silently moved.

By default, SCIM does not link an existing Omniio account with the same email. That operation returns a conflict; invite the existing account instead. This prevents possession of the provisioning token from attaching a company identity source to an independently created account.

When the IdP sends active: false, the person is blocked from signing in, removed from the active seat count, and kept in the roster as Deactivated. Reactivation restores the retained place rather than creating an unrelated record.

The team screen reports the number currently provisioned and deactivated from the accounts the connection actually created.

Rotation and disconnection#

Replacing a SCIM token stops the current token immediately; provisioning is unavailable until the new value is saved in the IdP. Revoking the SCIM connection stops future provisioning but does not deactivate or remove existing members.

Similarly, disconnecting OIDC does not revoke the SCIM token, and revoking SCIM does not disconnect OIDC. Operate them independently so rotating one integration does not create an accidental mass offboarding in the other.

Next: REST API.