SSO & SCIM Provisioning

What it is

SCIM 2.0 lets your identity provider — Okta, Microsoft Entra, OneLogin, JumpCloud, or any SCIM-capable IdP — automatically create, update, and deactivate TATER org members. The deprovisioning side is the compliance win: when HR offboards someone in the IdP, their TATER access is removed automatically, so your access reviews stay accurate without manual cleanup.

SCIM provisioning is independent of how users sign in — it works alongside the existing Entra (MSAL) and local sign-in. (SAML / OIDC single sign-on, i.e. logging in through your IdP, is a separate capability — see the note at the end.)

Enable SCIM (TATER Manage)

Open TATER Manage → Connections → SSO & SCIM (OrgAdmin / Admin).
Tick Enable SCIM provisioning and pick the default role for newly provisioned users (Viewer is the safe default).
Click Generate / rotate token. The token is shown once — copy it now.
Copy the SCIM base URL shown on the page.

Configure your IdP

Setting	Value
SCIM connector base URL	The SCIM base URL from the Manage page (`https://api.tatersecurity.com/api/scim/v2/<your-org-id>`)
Unique identifier / matching attribute	`userName` (the user's email)
Authentication mode	HTTP Header / OAuth Bearer Token
Bearer token	The token you generated (starts `scim_…`)
Provisioning actions	Create users, Update user attributes, Deactivate users

In Okta: add TATER as a SCIM 2.0 app, set SCIM connector base URL + Authentication Mode: HTTP Header, and enable Create / Update / Deactivate Users. In Entra: Enterprise app → Provisioning → Automatic, set Tenant URL = SCIM base URL and Secret Token = the token.

What provisioning does in TATER

Create — adds an org membership for the user with the default role (or links to an existing user with the same email).
Update — keeps name/attributes in sync.
Deactivate / Delete — removes the user's access to this org. The action is recorded in the Activity Log (channel scim) for audit.

Security

The SCIM token is SHA-256 hashed at rest — TATER never stores it in the clear, and it's shown only once.
Each token is scoped to one org and only allows SCIM user operations for that org.
Rotate the token any time from the Manage page; the old token stops working immediately.

OIDC single sign-on (login)

SCIM (above) handles who exists. OIDC single sign-on handles how they log in — letting users authenticate through your own identity provider instead of the built-in Microsoft or email sign-in. TATER uses the standard OpenID Connect authorization-code flow with PKCE, so it works with Microsoft Entra, Okta, Google Workspace, OneLogin, Ping, Auth0, and any OIDC-compliant IdP. It is disabled per organization until you turn it on — enabling it does not affect existing Microsoft / email login.

1. Create an OIDC app in your IdP

Register a new web / confidential application and set its redirect (callback) URI to the value shown on the TATER Manage → Connections → SSO & SCIM page (it is https://api.tatersecurity.com/api/auth/oidc/callback). Grant the openid, email, and profile scopes. Note the Issuer URL, Client ID, and Client Secret.

2. Configure TATER (Manage → Connections → SSO & SCIM → OIDC)

Issuer URL — TATER auto-discovers the authorization, token, and JWKS endpoints from {issuer}/.well-known/openid-configuration. (Entra: https://login.microsoftonline.com/{tenantId}/v2.0; Okta: https://your-org.okta.com; Google: https://accounts.google.com.)
Client ID and Client Secret (the secret is encrypted at rest and never shown again).
Allowed email domains — required. The login screen's "Sign in with SSO" matches a user's email domain to your org, and a user whose email domain isn't listed is rejected.
Auto-provision (optional) — when on, a first-time SSO user with no TATER account is created automatically with the chosen default role and an org membership. When off, only users who already have a TATER account + membership can sign in.
Tick Enable OIDC login and Save.

3. How users sign in

On the TATER login screen users click Sign in with SSO, enter their work email (matched to your org by domain), and are redirected to your IdP. After authenticating they return signed in. You can also hand out the direct login link shown on the config page (/api/auth/oidc/{orgId}/start) to skip the email prompt.

Security

Every flow uses single-use state, a nonce, and PKCE (S256).
The IdP id_token is verified against the IdP's JWKS (RS256), with issuer, audience, expiry, and nonce all checked before any session is issued.
The client secret is encrypted at rest; all IdP URLs are validated to block SSRF to internal hosts.
A successful SSO login mints the same short-lived TATER session token as local login and is recorded in the activity log (channel sso).

Note: OIDC covers virtually every modern IdP. SAML 2.0 (legacy) is not yet supported — if you require SAML specifically, contact us.