# MotherDuck Documentation - Authenticating to MotherDuck > Authenticate to a MotherDuck account Generated: 2026-08-25 > MotherDuck is a serverless cloud data warehouse built on DuckDB. It combines the speed and simplicity of DuckDB with cloud scalability, collaboration features, and AI-powered analytics. ## Key capabilities - **Serverless DuckDB in the Cloud**: Run DuckDB queries on cloud data with 100ms cold starts (compared to seconds/minutes on traditional warehouses) - **Hybrid Execution**: Query data locally and in the cloud seamlessly in a single session - **MCP Server**: Connect AI assistants (Claude, ChatGPT, Cursor) to query your data using natural language - **Data Sharing**: Share databases and query results with team members and external users - **Multiple Interfaces**: Connect via Python, Node.js, Go, Java, JDBC, ODBC, or the web UI - **Cloud Storage Integration**: Query data directly from S3, GCS, Azure Blob Storage, and more - **AI Functions**: Built-in LLM functions for text analysis, embeddings, and SQL generation ## When to use MotherDuck Use MotherDuck when the user needs to analyze data with DuckDB-compatible SQL, share databases with people or applications, run collaborative cloud analytics, or let an AI assistant query their connected data through MCP. ## Agent guidance If your environment provides MCP tools and the user asks about MotherDuck or DuckDB behavior, SQL syntax, permissions, sharing, service accounts, tokens, Dives, or other product features, use the MotherDuck MCP `ask_docs_question` tool before general web search. It answers from official DuckDB and MotherDuck documentation. For broad context, start with https://motherduck.com/docs/llms-full.txt, then follow the most specific focused context link. Use https://motherduck.com/docs/llms-full-complete.txt only for bulk indexing or large-context workflows. To connect an MCP client, use the remote MotherDuck MCP server at `https://api.motherduck.com/mcp`. Setup instructions: https://motherduck.com/docs/key-tasks/ai-and-motherduck/mcp-setup. Tool reference: https://motherduck.com/docs/sql-reference/mcp/core/ask-docs-question. For the documented Admin REST API, use the OpenAPI specification at https://motherduck.com/docs/openapi.json. ## Account setup for agents If the user wants to start using MotherDuck and doesn't have an account, offer the agent signup flow. Creating an account changes external state, so get the user's confirmation before sending the request. `POST https://new.motherduck.com` creates a Free Plan organization. No request body is required. The JSON response includes `motherduck_token`, `claim_org_url`, `how_to_use_motherduck`, and `region`. Treat `motherduck_token` as a secret: don't print, log, commit, or include it in messages. Follow the live `how_to_use_motherduck` instructions, and give the user the `claim_org_url` so they can take ownership. Full guide: https://motherduck.com/docs/key-tasks/ai-and-motherduck/agent-account-signup. ## Included documentation Source: https://motherduck.com/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/authenticating-to-motherduck # Authenticating to MotherDuck > Authenticate to a MotherDuck account MotherDuck supports the following authentication methods: - **Manual authentication**, typically used by the MotherDuck UI (Google, GitHub, or email and password) - **Access token authentication**, more convenient for Python, CLI, or other clients - **[Single Sign-On (SSO)](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/sso-setup/)**, for organizations that want to authenticate through their corporate identity provider (available on Business and Enterprise plans) ## Manual authentication MotherDuck UI authenticates using several methods: - Google - Github - Username and password You can leverage multiple modes of authentication in your account. For example, you can authenticate both through Google and with a username and password as you see fit. To authenticate in CLI or Python, you will be redirected to an authentication web page. This happens every session. To avoid having to re-authenticate, you can save your access token, as described in the [Authenticate With an Access Token](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/#authentication-using-an-access-token) section. ## Authentication using an access token If you are using Python or CLI and don't want to authenticate every session, you can securely save your credentials locally. ### Creating an access token To create an access token: - Go to the [MotherDuck UI](https://app.motherduck.com) - In top left click on organization name and then `Settings` - Click `+ Create token` - Specify a name for the token that you'll recognize (like "DuckDB CLI on my laptop") - Specify the type of token you want. Tokens can be Read/Write (default) or [Read Scaling](/docs/key-tasks/authenticating-and-connecting-to-motherduck/read-scaling/). - Choose whether you want the token to expire and then click on `Create token` - Copy the access token token to your clipboard by clicking on the copy icon ![Access tokens settings page](../img/tokens.png) ### Storing the access token as an environment variable You can save the access token as `motherduck_token` in your environment variables. An example of setting this in a terminal: ```bash export motherduck_token='' ``` You can also add this line to your `~/.zprofile` or `~/.bash_profile`, or store it in a `.env` file in your project root. Once this is done, your authentication token is saved and you can connect to MotherDuck with the following connection string: ```bash duckdb "md:my_db" ``` :::info This is the best practice for security reasons. The token is sensitive information and should be kept safe. Do not share it with others. ::: Alternatively, you can specify an access token in the MotherDuck connection string: `md:my_db?motherduck_token=`. ```bash duckdb "md:my_db?motherduck_token=" ``` When in the DuckDB CLI, you can use the `.open` command and specify the connection string as an argument. ```CLI .open md:my_db?motherduck_token= ``` ## Using connection string parameters ### Authentication using SaaS mode You can limit MotherDuck's ability to interact with your local environment using `SaaS Mode`: - Disable reading or writing local files - Disable reading or writing local DuckDB databases - Disable installing or loading any DuckDB extensions locally - Disable changing any DuckDB configurations locally This mode is useful for third-party tools, such as BI vendors, that host DuckDB themselves and require additional security controls to protect their environments. You can enable SaaS mode in two ways: 1. **Using a configuration setting** (recommended for persistent configuration): ```sql SET motherduck_saas_mode = true; ``` 2. **Using a connection string parameter** (for connection-time configuration): ### CLI ```cli .open md:[]?[motherduck_token=]&saas_mode=true ``` ### Python ```python conn = duckdb.connect("md:[]?[motherduck_token=]&saas_mode=true") ``` :::info Using the connection string parameter requires to use `.open` when using the DuckDB CLI or `duckdb.connect` when using Python. This initiates a new connection to MotherDuck and will detach any existing connection to a local DuckDB database. You cannot provide a token to `ATTACH md:` directly, only when connecting. ::: ### Using attach mode By default, MotherDuck connects in **workspace mode**, which attaches every database in your saved workspace and keeps attachment changes in sync across parallel connections. To scope the connection to a single database instead, use **single mode** by appending `?attach_mode=single` to the connection string. Single mode is useful for BI tools and other clients that get confused by multiple attached databases. For full details, see [Attach modes](/key-tasks/authenticating-and-connecting-to-motherduck/attach-modes/). For example, to connect to a database named `my_database` in single mode, run: ```bash duckdb 'md:my_database?attach_mode=single' ``` :::note `` that starts with a number cannot be connected to directly. You will need to connect without a database specified and then `CREATE` and `USE` using a double quoted name. Eg: `USE DATABASE "1database"` ::: --- Source: https://motherduck.com/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/sso-setup # Setting up SSO > Configure Single Sign-On (SSO) for your MotherDuck organization using your identity provider. Single Sign-On (SSO) allows your organization to authenticate MotherDuck users through your existing identity provider (IdP). When SSO is enabled, users with a verified email domain are automatically redirected to your corporate login page, removing the need for separate MotherDuck credentials. :::note SSO is available on **Business** and **Enterprise** plans. ::: ## How SSO works When you configure SSO, MotherDuck connects to your identity provider using either the SAML or OIDC protocol. The login flow works as follows: 1. A user enters their email on the MotherDuck login page. 2. MotherDuck looks up the email domain. If the domain is verified and SSO is enabled, the user is redirected to your corporate IdP. 3. The user authenticates with the IdP. 4. MotherDuck receives the authentication response and creates or updates the user's session. Users with personal email addresses or domains without SSO configured continue to use standard login methods (Google, GitHub, or email and password). ## Supported SSO configurations MotherDuck supports four SSO configuration options: | Configuration | Protocol | Use when | | --- | --- | --- | | **Okta** | OIDC | Your organization uses Okta Workforce Identity | | **Microsoft Entra ID** | OIDC | Your organization uses Microsoft Entra ID (formerly Azure AD) | | **SAML** | SAML | Your IdP supports SAML but is not Okta or Entra ID | | **OIDC** | OIDC | Your IdP supports OpenID Connect but is not Okta or Entra ID | The generic SAML and OIDC options allow you to connect any compatible identity provider, such as Google Workspace, PingFederate, or Keycloak. ### SAML vs. OIDC **SAML** (Security Assertion Markup Language) is an XML-based protocol widely used in enterprise environments for browser-based SSO. Most traditional enterprise IdPs support SAML. **OIDC** (OpenID Connect) is a JSON-based protocol built on top of OAuth 2.0. It is more common in cloud-native and modern environments. Both protocols achieve the same result: authenticating users through your IdP. Choose the protocol that your IdP supports or that your IT team is most familiar with. ## Prerequisites Before setting up SSO, ensure you have: - Permission to configure SSO in your MotherDuck organization. The Admin preset role includes this permission by default. - A **Business** or **Enterprise** plan - Admin access to your company's identity provider - A **custom domain name** for your organization (for example, `acme.com`) and the ability to add a DNS TXT record to the domain for verification - All users in your organization use **non-aliased email addresses** (addresses like `user+tag@company.com` are not supported) :::caution SSO is supported for organizations where all users belong to a **single MotherDuck organization**. If your users are spread across multiple MotherDuck organizations (for example, separate US and EU orgs), do not enable SSO. Multi-organization SSO support is planned for a future release. ::: ## Setting up SSO ### Step 1: Start SSO configuration in MotherDuck 1. In the MotherDuck UI, click your organization name in the top left and select **Settings**. 2. Navigate to the **Authentication** tab. 3. Click **Set up SSO** to begin the setup process. ![MotherDuck Settings showing the Authentication tab with the Set up SSO button](./img/sso-authentication-settings.png) 4. Select your identity provider from the list, or choose **Custom SAML** or **Custom OIDC** if your IdP is not listed. ![Select your identity provider for SSO configuration](./img/sso-select-identity-provider.png) ### Step 2: Create a MotherDuck application in your identity provider 1. Log in to your identity provider's admin console. 2. Create a new application and name it **MotherDuck**. 3. Select the appropriate protocol (SAML or OIDC) based on your chosen configuration. ### Step 3: Configure the connection The MotherDuck setup wizard provides step-by-step instructions for each provider. Follow the instructions on the SSO onboarding portal to configure the connection between your IDP and MotherDuck. For example, the Okta configuration walks you through creating an OIDC application: ![Okta OIDC SSO configuration wizard showing the Create Application step](./img/sso-okta-create-application.png) ### Step 4: Map user attributes In your IdP, map the following attributes to the MotherDuck application: | Attribute | Required | Description | | --- | --- | --- | | `email` | Yes | The user's email address (primary login identifier) | | `given_name` | No | The user's first name | | `family_name` | No | The user's last name | ### Step 5: Assign users Assign yourself (and optionally other users) to the MotherDuck application in your IdP. ### Step 6: Verify your domain MotherDuck requires domain ownership verification before SSO can be enabled. Follow the instructions to add a DNS TXT record for your domain. Once the record is detected, your domain is verified. ![SSO configuration status showing pending domain verification](./img/sso-pending-domain-verification.png) ### Step 7: Enable SSO After domain verification succeeds, return to the setup wizard and click **Done** to complete the configuration, then click **Enable SSO** to activate the connection. ![SSO configuration dialog to confirm enabling SSO](./img/sso-enable-sso-dialog-confirmation.png) :::warning Enabling SSO is **not reversible** without contacting MotherDuck support. Before enabling, ensure that: - All users in your organization use non-aliased email addresses on the verified domain - Your users belong to **only this** MotherDuck organization - You have tested the IdP configuration by assigning yourself to the application ::: When SSO is enabled: - All existing non-SSO login methods (Google, GitHub, email/password) are **deactivated** for users with the verified domain - Any pending invitations matching the SSO domain will need to **sign up through SSO** - Users must authenticate through the configured IdP going forward ### Step 8: Test SSO login 1. Log out of MotherDuck. 2. On the login page, enter your corporate email address. 3. You should be redirected to your IdP's login page. 4. After authenticating, you are returned to the MotherDuck UI. ## Just-in-Time (JIT) user provisioning When SSO is enabled, new users from your verified domain can be automatically provisioned on their first login. This is called Just-in-Time (JIT) provisioning. JIT provisioning is enabled by default the first time you activate SSO. Changing this setting requires permission to manage the organization invite policy, which the Admin preset role includes by default. With JIT enabled: - A user enters their corporate email on the MotherDuck login page - They are redirected to your IdP and authenticate - The user is automatically given the option to join your organization at signup ### Controlling access with JIT and invite settings Configuring JIT provisioning requires permission to configure SSO. Changing the organization invite policy requires a separate permission to manage the invite policy. The Admin preset role includes both permissions by default. These two settings work together to control how new users join your organization: | Setting | When enabled | When disabled | | --- | --- | --- | | **JIT provisioning** | Users who authenticate through your IdP can join the organization on first sign-in *(default on first SSO activation)* | New users must be invited by someone with permission to invite members | | **Organization invites** | The invite policy grants members permission to invite others | Only roles that include permission to invite members can invite new users | When both organization invites and JIT provisioning are disabled, new users can only join if someone with permission to invite members invites them. When JIT is enabled but member invitations are disabled, users who have access in your IdP can still join on first sign-in. ![invite policy](./img/org-invite-policy.png) For more information on managing organization members and roles, see [Managing organizations](/docs/key-tasks/managing-organizations/). JIT provisioning handles initial account creation only. It does not manage role changes or account deletion after provisioning. For automated user lifecycle management, see [SCIM provisioning](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/scim/). ### How SCIM affects JIT and invites When SCIM provisioning is enabled, MotherDuck delegates user lifecycle to your IdP. SCIM replaces JIT as the auto-provisioning mode, and organization invites are automatically disabled (the **Invite policy** setting is locked). To re-enable manual invites or fall back to JIT, [disable SCIM](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/scim/#disabling-scim) from the Authentication settings page. :::warning If you disable SCIM and then change members from inside MotherDuck, the user state in MotherDuck and your IdP will drift. Either keep SCIM enabled and manage users in your IdP, or disable SCIM and accept that the two systems are no longer in sync. ::: ## Managing members Managing users with SSO works the same as before. You can invite any new user by supplying their email address. If the email domain matches one of your verified domains, the user will be redirected to their IdP for authentication. :::note **Everyone in an SSO-enabled organization signs in with an email on one of your verified domains.** To give an external collaborator or contractor access, provision a dedicated email address on a verified domain (for example, `contractor-name@yourcompany.com`). Your organization can then manage the account through your IdP. ::: If you have [SCIM provisioning](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/scim/) enabled, manual invites are disabled. Users are created automatically when you assign them to the MotherDuck application in your IdP, and deprovisioned when you unassign them. To hard-delete a user's record from MotherDuck, explicitly delete the user in your IdP — deprovisioning alone keeps the record for later reprovisioning. ## Limitations - **Single organization only**: SSO is supported for users who belong to a single MotherDuck organization. Multi-org SSO is planned for a future release. - **No aliased emails**: Email addresses with aliases (for example, `user+tag@company.com`) are not supported when SSO is enabled. - **One connection per domain**: Each verified domain can have only one SSO connection. Users with an email address on that domain in any MotherDuck organization will be redirected to their IdP. - **Non-reversible**: Enabling SSO cannot be undone without contacting [MotherDuck support](mailto:support@motherduck.com). - **CLI and SDK authentication**: Users authenticating through the SDKs continue to use [access tokens](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/#authentication-using-an-access-token). SSO applies to browser-based login flows for the WebUI, CLI and MCP. --- Source: https://motherduck.com/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/scim # Setting up SCIM provisioning > Automate user lifecycle management in MotherDuck using SCIM with your identity provider. SCIM (System for Cross-domain Identity Management) keeps your MotherDuck users in sync with your identity provider. When you assign, update, or remove a user in your IdP, the change is automatically applied in MotherDuck. :::note SCIM provisioning is available on **Business** and **Enterprise** plans, and requires an active [SSO connection](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/sso-setup/). ::: ## How SCIM complements SSO SSO and SCIM solve different problems: | | SSO | SCIM | | --- | --- | --- | | **Purpose** | Authentication — controls **how** users sign in | Provisioning — controls **which** users exist | | **Handles** | Sign-in redirects, session management | Account creation, updates, deprovisioning | | **Trigger** | User-initiated (at sign-in) | IdP-initiated (when staff changes) | With SSO alone, MotherDuck uses [just-in-time (JIT) provisioning](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/sso-setup/#just-in-time-jit-user-provisioning) to create accounts on first sign-in. JIT does not handle changes after the account is created — if an employee leaves your company, their MotherDuck account stays active until someone with permission to deprovision members or remove members [does so manually](/docs/key-tasks/managing-organizations/#deprovisioning-users). SCIM closes that gap by making your IdP the source of truth for who has access. SCIM replaces JIT as the auto-provisioning mode and disables manual invite flows, so the IdP becomes the only place where members are added or removed. ## Prerequisites Before you enable SCIM, confirm: - Permission to configure SCIM in MotherDuck. The Admin preset role includes this permission by default. - A **Business** or **Enterprise** plan. - An [SSO connection](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/sso-setup/) that is **active** (not pending). SCIM cannot be enabled on a pending connection. - Admin access to the IdP application that's already linked to your SSO connection. Configuring SCIM uses your existing SSO connection, so any of the supported enterprise SSO connection types work — **SAML**, **OIDC**, **Okta Workforce**, or **Microsoft Entra ID** (Azure AD). ## Supported operations | IdP action | Effect in MotherDuck | | --- | --- | | Assign user to the MotherDuck application | Creates a MotherDuck user with the **Explorer** role on first SCIM event | | Update user attributes (name, email) | Updates the MotherDuck user record | | Deprovision user | Deprovisions the user — sign-in is blocked, all access tokens are revoked, but data is retained and the account can be reprovisioned | | Reprovision user | Restores a deprovisioned user to active status | | Unassign / delete user | Removes the user from the organization (hard delete) | Role assignment through SCIM is not yet supported — all SCIM-provisioned users start with the **Explorer** role. Changing a user's role after provisioning requires permission to assign roles, which the Admin preset role includes by default. Use the MotherDuck **Members** page to make the change. ## Attribute mapping MotherDuck reads the following attributes from each SCIM request: | SCIM attribute | Required | Description | | --- | --- | --- | | `userName` | Yes | The user's email address. Must be on a [verified domain](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/sso-setup/#step-6-verify-your-domain) of the SSO connection. | | `emails[].value` | Yes (if `userName` is not set to email) | Used as a fallback for the email address. | | `name.givenName` | No | The user's first name. | | `name.familyName` | No | The user's last name. | | `active` | Yes | Drives deprovisioning and reprovisioning. | User email addresses with aliases (for example, `user+tag@company.com`) are not supported, matching the SSO requirement. ## Enabling SCIM ### Step 1: Generate the SCIM endpoint and token in MotherDuck 1. In the MotherDuck UI, click your organization name in the top left and select **Settings**. 2. Open the **Authentication** tab. 3. In the **SCIM** section, click **Enable SCIM**. 4. Confirm in the dialog. MotherDuck generates a SCIM endpoint URL and a SCIM token. The endpoint URL has this shape: ```text https://auth.motherduck.com/scim/v2/connections/ ``` :::warning The SCIM token is shown **once**. Copy it immediately and store it in your IdP — MotherDuck cannot show it again. If you lose the token, you can regenerate it (which revokes the previous token). ::: ### Step 2: Configure SCIM provisioning in your identity provider In your IdP's admin console, open the application that's linked to your MotherDuck SSO connection and turn on SCIM provisioning. The exact path depends on the IdP: - **Okta**: open the application's **Provisioning** tab and switch to **SCIM**. - **Microsoft Entra ID**: open the application's **Provisioning** blade and set the mode to **Automatic**. When prompted, supply: - **Tenant URL** (also called **SCIM endpoint URL** or **Base URL**): paste the URL from Step 1. - **Secret token** (also called **Bearer token**): paste the SCIM token from Step 1. Use the IdP's **Test Connection** button to verify connectivity before assigning users. ### Step 3: Map attributes in your identity provider Map your IdP's user attributes to the SCIM attributes [listed above](#attribute-mapping). Most IdPs ship a default mapping that already covers `userName`, `emails`, `name.givenName`, `name.familyName`, and `active`. ### Step 4: Assign users Assign users (or groups) to the MotherDuck application in your IdP. Each assignment triggers a SCIM `create` request, which provisions the user in MotherDuck with the **Explorer** role. For ongoing changes, your IdP automatically sends: - A SCIM `update` request when a user's attributes change. - A SCIM `update` or `patch` request with `active=false` when a user is deprovisioned or unassigned. - A SCIM `delete` request when the user is fully removed. ## Managing SCIM after enablement ### Regenerating the token If the SCIM token is lost or compromised, regenerate it from **Settings → Authentication → SCIM → Regenerate token**. The previous token is revoked immediately, so update the new token in your IdP right away to avoid provisioning failures. ### Disabling SCIM To stop SCIM provisioning, click **Disable SCIM** on the **Authentication** page. Disabling: - Removes the SCIM connection from MotherDuck's identity layer (your IdP can no longer make SCIM requests). - Switches auto-provisioning back to [JIT](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/sso-setup/#just-in-time-jit-user-provisioning). - Leaves existing user accounts untouched. Previously deprovisioned users remain deprovisioned. You can re-enable SCIM later, but a new endpoint URL and token will be issued. ### Manual invites are disabled and JIT is replaced When SCIM is enabled, MotherDuck switches the auto-provisioning mode from JIT to SCIM and disables manual invite flows, so the IdP stays the single source of truth for who can sign in: - The **Invite** action in the org menu and on the Members page is disabled. - The **Invite policy** setting on the org details page is disabled. To grant a new user access, assign them to the MotherDuck application in your IdP. ### Deprovisioned users on the members page Deprovisioned users appear on the **Members** page with a `deprovisioned` badge. Hover the badge for a reminder that the user can no longer sign in and that all of their access tokens have been revoked. The Members page status filter lets you narrow the list to **active**, **invited**, or **deprovisioned** users. Impersonating a deprovisioned user requires permission to impersonate deprovisioned members, which the Admin preset role includes by default. Impersonating a service account requires a separate permission, which the Admin and Builder preset roles include by default. Active human users cannot be impersonated. ## Deletion vs. deprovisioning Deprovisioning and deletion are distinct user states with different recovery semantics: | State | What happens | How to enter | How to exit | | --- | --- | --- | --- | | **Deprovisioned** | The user record and data are retained, the identity is disabled, and all PATs and short-lived tokens are revoked. The user cannot sign in. A user with the required impersonation permission can still impersonate the account. | IdP sends `active=false` (PATCH or PUT) | Reprovision the user in your IdP — works at any time, including past the deletion fail-safe window | | **Deleted** | The user is removed from the organization. Email is freed for reuse. No one can impersonate a deleted account. | IdP sends a SCIM `delete` request | Restore the account within the **7-day fail-safe** window through MotherDuck support | ### How deletion is triggered - **From the IdP (SCIM orgs)**: removing the user from the MotherDuck application — or deleting them from the IdP entirely — sends a SCIM `delete` event when your IdP is configured to forward delete events. SCIM-enabled organizations cannot hard-delete users from inside MotherDuck; the IdP is the only authoritative path. - **From inside MotherDuck (non-SCIM orgs only)**: the in-app **Remove member** action is available only when SCIM is disabled. :::note Some IdPs do not forward delete events to applications by default — they only mark the user inactive on their side. In that case, MotherDuck sees the inactive signal and the user appears as **deprovisioned** rather than deleted. Configure your IdP to forward delete events if you want hard deletes to flow through. ::: ### Restoring after deprovisioning or deletion - A **deprovisioned** user can be reprovisioned at any time from your IdP. The next SCIM event will restore their account. Their data is preserved, but issued access tokens are not — affected users need to mint new tokens. - A **deleted** user can be restored within the **7-day fail-safe** window by contacting [MotherDuck support](mailto:support@motherduck.com). After the window elapses, the account and its data are gone. ## Limitations - **One SCIM connection per organization**: SCIM uses the same Auth0 connection as SSO. Each MotherDuck organization can have only one SCIM connection, matching its single SSO connection. - **No role mapping yet**: SCIM-provisioned users start as **Explorer**. Adjusting roles in MotherDuck after provisioning requires permission to assign roles, which the Admin preset role includes by default. - **No aliased emails**: Addresses like `user+tag@company.com` are rejected, the same as for SSO. - **PATCH `remove` operations are ignored**: MotherDuck handles SCIM `add` and `replace` operations on `active`. `remove` operations are logged and skipped to keep behavior predictable across IdPs. ## Related - [Setting up SSO](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/sso-setup/) - [Managing organizations](/docs/key-tasks/managing-organizations/) --- ## Docs feedback MotherDuck accepts optional user-submitted feedback about this page at `GET https://motherduck.com/docs/api/feedback/agent`. For agents and automated tools, feedback submission should be user-confirmed before sending. URL-encode query parameter values and send a GET request: ```text GET https://motherduck.com/docs/api/feedback/agent?page_path=%2Fkey-tasks%2Fauthenticating-and-connecting-to-motherduck%2Fauthenticating-to-motherduck%2F&page_title=MotherDuck%20Documentation%20-%20Authenticating%20to%20MotherDuck&text= ``` Optionally append `&source=` such as `claude.ai` or `chatgpt`. `page_path` and `text` are required; `page_title` and `source` are optional. Responses: `200 {"feedback_id": ""}`, `400` for malformed query parameters, and `429` when rate-limited.