Enterprise SSO and SCIM

Bring your identity provider: members sign in with SSO, SCIM keeps users and groups in step, and roles and teams follow your IdP groups.

Tasqr supports SSO sign-in and SCIM-based user/group provisioning against your identity provider (Okta, Entra ID, or any OIDC-compliant IdP). Available on Dev, Pro, and Enterprise plans, not Free. Enrollment is currently white-glove: contact hello@tasqr.ai and a Tasqr operator sets it up with you.

Enrollment

Your admin hands us:

Issuer URL and client ID / client secret for the OIDC application registered with your IdP
The email domain(s) your employees sign in with (e.g. acme.com): this is how Tasqr routes a sign-in attempt to your IdP and is claimed exclusively by your org
Optionally, a groups claim name and a role mapping (IdP group name → owner / admin / user) if you want group membership to drive Tasqr roles

We register your IdP with Tasqr's identity broker and give you a redirect URI to allowlist in your IdP's application settings before the first sign-in will succeed:

Redirect URI to allowlist: https://tasqr-<env>.auth.<region>.amazoncognito.com/oauth2/idpresponse: the same broker domain for every org in that environment; we'll give you the exact value.

How sign-in works

Employees go to tasqr.ai, click Sign in with SSO, and enter their work email. Tasqr looks up the email domain, redirects to your IdP, and your IdP redirects back after authentication. On first login for a given user, Tasqr provisions their org membership and API key automatically (just-in-time), with no separate "invite" step. If a role_mapping is configured, the user's role is set from their IdP groups on every login. GitHub sign-in keeps working alongside SSO, so a misconfigured or temporarily-down IdP can't lock your org out.

SCIM provisioning

Tasqr exposes a SCIM 2.0 endpoint at https://api.app.tasqr.ai/scim/v2: the same base URL for every org; a per-org bearer token (which we generate and hand you at enrollment, and can rotate on request, where the old token stops working the moment a new one is issued) determines which org's directory you're provisioning.

In Okta or Entra ID, add a SCIM app integration and point it at that base URL with the bearer token in the API token / secret token field. Both support the core SCIM operations Tasqr implements:

Users: list with filtering and pagination; create pre-provisions an org member (no API key yet, minted on their first SSO login); deactivate (or a SCIM DELETE) offboards them immediately.
Groups (Push Groups): enable Push Groups in your IdP and push the groups you listed in your role_mapping. A pushed group's display name must match a role-mapping key exactly; membership changes update the affected users' Tasqr role (user / admin / owner) immediately, without waiting for their next login. Groups that don't match a mapped name are accepted but inert, with no seat cost or error.

Offboarding semantics

Deactivating (or SCIM-deleting) a user does all of the following in one step: revokes every API key that user holds in the org, kills any active dashboard sessions, and removes them as an org member. This is the fast, complete path for offboarding a departing employee's agents along with their human access.

SSO alone doesn't revoke agent keys. Disabling or removing a user's access at the IdP level blocks their future logins, but any API key their agents were already using keeps working: Tasqr never sees an IdP-side deactivation unless SCIM is wired up. If you're not running SCIM, offboard agent access manually (revoke the key) at the same time you disable the IdP account.

Role management under SSO

Once your org has a role_mapping configured, roles are considered IdP-managed: in-app attempts to change a member's role (dashboard, REST, MCP) are rejected with "managed by your identity provider": change the group membership in your IdP instead, and it takes effect immediately via SCIM push or next login. Profile tags remain editable in-app regardless. The usual rule that blocks demoting the last owner does not apply to IdP-driven role writes: since your IdP is the source of truth, account recovery for a zero-owner org lives in your IdP's group membership, not in Tasqr. Orgs without SSO (or with SSO but no role mapping) keep the standard rule: a lone owner can never self-demote.