# SailPoint Stytch Connector Documentation

> Stytch Connector Documentation

# Documentation

# Connecting SailPoint and Stytch

To connect SailPoint to the source, perform the following tasks:

## Adding and Configuring the Source in SailPoint

To connect to SailPoint, perform the following steps. Once the connection is made, you can configure it to meet your company's needs.

1. Go to **Admin \> Connections \> Sources**.
2. Select **Create New**.
3. Search for a source type and select **Actions**.
4. In the **Actions** dropdown, select the setup method:

   - **Express Setup** - Quickly create a read-only connection to your target system by providing minimal configurations and authentication. On completion, aggregation is automatically started.

     > **Note**
     >
     > Express Setup supports Credential Providers. For information on supported credential providers and configuration, refer to [Credential Providers](<https://documentation.sailpoint.com/connectors/help/credential_providers.html>). For more information, contact your SailPoint Customer Service Manager.
   - **Standard Setup** - Provide detailed basic configuration to create the source. Once the source is created, continue with source setup.

### Express Setup

1. Review the directions and select **Start Express Setup**.
2. Review the pre-populated source name, source owner, and description. To update, select **Edit**.

   > **Note**
   >
   > Source name must be unique.
3. (Optional) If enabled for your organization, select the **Use a Credential Provider** checkbox to manage the source's authentication using a credential provider.

   > **Note**
   >
   > To add a Credential Provider in SailPoint, go to **Admin \> Connections \> Credential Providers**. For more information about credential providers, refer to [Credential Providers](<https://documentation.sailpoint.com/connectors/help/credential_providers.html>).
4. Configure the authentication to allow SailPoint to connect to the source. For more information, refer to the **Connection Settings** page.
5. Select **Finish**. After a successful test connection, the system creates your source and prompts you to run an aggregation.

   - If you want to aggregate now, select **Aggregate**.

     - To see the latest account aggregation history, go to **Account Management \> Account Aggregation**.
     - To see the list of aggregated source accounts, go to **Account Management \> Accounts**.
   - If you want to aggregate later, select **Exit**. This returns you to the **Sources** page. Your new source is listed, but contains no accounts or aggregation history yet.

### Standard Setup

Configure more detailed settings relative to Express Setup.

1. In the **Source Name** field, enter a unique and descriptive name for your source. Source names cannot exceed 128 characters.
2. In the **Description** field, provide additional details about the source to help distinguish it from similar sources. This field allows a maximum of 2,000 characters.
3. In the **Source Owner** field, begin typing the name of an owner. Matches appear after you type two or more letters. For more information, refer to [Assigning a Source Owner](<https://documentation.sailpoint.com/saas/help/sources/index.html#assigning-a-source-owner>).
4. (Optional) Select a governance group to grant its members [source](<https://documentation.sailpoint.com/saas/help/common/users/user_levels.html#source-sub-admin-user-level>) or [role](<https://documentation.sailpoint.com/saas/help/common/users/user_levels.html#role-sub-admin-user-level>) sub-admin level oversight of the source and its access. For more information, refer to [Creating and Managing Governance Groups](<https://documentation.sailpoint.com/saas/help/common/users/governance_groups.html>).
5. If this source represents a primary system containing your organization's personnel records, select the **Authoritative Source** checkbox. For more information, refer to [Creating Identity Profiles](<https://documentation.sailpoint.com/saas/help/setup/identity_profiles.html>).
6. Select **Continue**. The source is created, and you are navigated to the **Source Setup \> Base Configuration** page. Here, continue to configure your connected source.

## Base Configuration

Provide the base configuration parameters. Information you entered in the Create New Source dialog is automatically entered into the fields in the Base Configuration page. You can edit this information if necessary.

1. Enter a descriptive **Source Name** for the connection.
2. Enter the **Source Description** that provides details necessary to distinguish it from similar connection sources.
3. In **Source Owner**, begin typing the name of the source owner.
4. (Optional) Select the appropriate **Governance Group for Source Management** from the dropdown list. For more information about governance groups, refer to [Associating Governance Groups with a Source](<https://documentation.sailpoint.com/saas/help/common/users/governance_groups.html#associating-a-governance-group-with-a-source>).
5. Select **Create Manual Work Items** to enable the source to support additional source management features such as creating accounts and access profile management.

   > **Important**
   >
   > Once you enable this feature, it can't be disabled.

   For more information on manual work items, refer to [Work Items](<https://developer.sailpoint.com/docs/api/work-items>). For more information on SailPoint features, refer to [SailPoint Identity Services](<https://documentation.sailpoint.com/saas/help/index.html>).
6. Select **Save**.

## Connection Settings

Configure a secured, direct connection to the source.

1. In the **Base URL** field, enter the base URL for the web service endpoint. For example:

   `https://<test>.stytch.com`

   This is a required field. Key: `genericWebServiceBaseUrl` 2. In the **Username** field, enter the username for authentication. This is a required field. Key: `username` 3. In the **Password** field, enter the password associated with the username. This is a required field. Key: `password` 4. In the **Organization ID** field, enter the unique identifier for the organization. This is a required field. Key: `orgId` 5. Select **Save**.

## Review and Test

Perform a test to confirm the connection to SailPoint.

1. Go to **Review and Test**.
2. Confirm that the entries in each field are correct.

   If you note any mistakes, return to the section and make corrections.
3. Select **Test Connection**.

## SailPoint Application Onboarding

SailPoint application onboarding enables you to easily onboard new applications and create sources following the successful onboarding of a discovery source. To use this feature, continue to **Discovered Applications** in the SailPoint user interface.

For more information, refer to [Application Onboarding](<https://documentation.sailpoint.com/saas/help/ai/app_onboarding/index.html>) in the SailPoint SaaS documentation.

# Integrating SailPoint with Stytch

Stytch is an identity and access management company that provides a developer-first platform for authentication and user management. It helps businesses build secure, seamless, and scalable login flows with a comprehensive suite of APIs for methods like passwordless magic links, OTPs, OAuth, biometrics, and B2B-focused features like organization management and SSO.

This document provides instructions to configure a new direct connection to a Stytch source.

For a reference to the terminology specific to SailPoint products, refer to [Source and Connector Definitions](<https://documentation.sailpoint.com/saas/help/sources/index.html#source-and-connector-definitions>).

> [!NOTE]
>
> To view the latest features, enhancements, and fixes for all SaaS connectors, refer to the [SaaS Release Notes](<https://community.sailpoint.com/release-notes/saas>) page.

## Supported Features

The Stytch connector supports the following:

### Account Management

- Aggregate Accounts

### Entitlement Management

- Aggregate Groups
- Aggregate Roles

> [!IMPORTANT]
>
> Quick Compliance connectors have the following manual aggregation limits within a 24-hour period:
>
> - **Organization Admins**: Limited to 3 manual account or entitlement aggregations per day per source. This limit is cumulative across all admins in the organization.
> - **Regular Users**: Limited to 1 manual account or entitlement aggregation per day per source.
>
> These limits ensure that individual compliance statuses are kept up to date while maintaining continuous compliance monitoring. If you need to run additional aggregations beyond these limits, contact SailPoint Support.

## Supported Managed System

- Stytch API (v1)

## Prerequisites

To successfully integrate with and manage the Stytch system, the following prerequisites must be met. These credentials allow for secure authentication and access to the Stytch API for user management and authentication workflows.

- **Admin Access to the Stytch Dashboard**

  You must have administrative or member access to your organization's Stytch Dashboard. This is required to access API keys, configure project settings, and view user data.
- **An Active Stytch Project**

  Your integration will be scoped to a specific project within your Stytch account. You will need credentials for the environment you intend to use (either Test or Live).
- **API Key Authentication Credentials**

  Stytch uses a `project_id` and a `secret` to authenticate API requests. Both are required for a successful connection.

  - `project_id`: A unique public identifier for your Stytch project.
  - `secret`: A private API key used to authenticate server-side requests to the Stytch API. This key must be kept confidential.
- **Official Documentation for Generating Credentials**

  For detailed instructions on how to locate your Project ID and Secret within the Stytch Dashboard, refer to the official developer documentation:

  **Reference**: [B2B SaaS Authentication API Reference - API keys](<https://stytch.com/docs/b2b/api/overview>)

  > **Note**
  >
  > The linked document is not maintained by SailPoint and is subject to change without notice.

## Required Permissions

Stytch's authentication model differs from systems that rely on granular OAuth scopes. Access is primarily controlled through API keys, which grant broad access to a project's resources, and role-based access control for users of the Stytch Dashboard.

1. API Key Authentication

   The primary method for granting permissions to an application or service is by providing it with your Project's API keys. Stytch provides two distinct sets of keys for different environments.

   - **Test API Keys**: Used for development and testing purposes. All API requests made with these keys operate in a sandboxed test environment and will not affect your live user data.
   - **Live API Keys**: Used for your production application. These keys interact with your real user data and live configuration. They should be kept confidential and stored securely.

   Each set of keys consists of a `project_id` and a `secret`. The `secret` is the sensitive credential that authenticates your API requests.

   **Permissions Granted by API Keys:**

   A Stytch API key (`project_id` and `secret`) grants full programmatic access to all API endpoints associated with that Project. This includes, but is not limited to, the ability to:

   - Authenticate users (Magic Links, OTPs, OAuth, etc.)
   - Create, retrieve, update, and delete users
   - Manage organizations and members (B2B products)
   - Manage sessions
   - Validate JWTs

   > **Important**
   >
   > Unlike OAuth 2.0, Stytch does not currently provide granular, scope-based permissions to restrict an API key's access to specific endpoints (e.g., a "read-only" API key). A valid key grants comprehensive access to its corresponding environment (Test or Live).

   For instructions on how to locate your keys, refer to [Stytch API keys](<https://stytch.com/docs/workspace-management/api-keys>) in the Stytch documentation.

   > **Note**
   >
   > The linked document is not maintained by SailPoint and is subject to change without notice.
2. Dashboard User Roles &amp; Permissions

   To manage managing access to the Stytch Dashboard itself, Stytch uses a Role-Based Access Control (RBAC) system. These permissions are for human users managing the project and do not apply to API requests.

   The predefined roles are:

   - **Owner**: Has full access to the project, including managing billing, deleting the project, and managing team members.
   - **Admin**: Has full access to configure project settings and view data but cannot manage billing or team members.
   - **Read-only**: Can view all project settings and data but cannot make any changes.

### Summary of Permissions

| Access Type | Method of Authentication | Scope of Permission |
| --- | --- | --- |
| API Access | API Key<br>`project_id` &amp; `secret` | Grants full read/write access to all API resources within the key's environment (Test or Live). |
| Dashboard Access | Stytch Team Member Account | Permissions are determined by the assigned user role (Owner, Admin, or Read-only). |

# Schema Reference

The application schema is used to configure the objects returned from a connector.

> [!NOTE]
>
> - The **Account Schema** tab is used to define the attributes for each object type in the application being configured. The schema attributes can be defined as **Entitlement** or **Multi-Valued**. Refer to [Managing Source Account Schemas](<https://documentation.sailpoint.com/saas/help/accounts/schema.html>) for more information.
> - The schema attributes that are not present by [default](<#default-account-schema>) must be defined as strings if not specified.

The Stytch connector uses the following default correlation and object configurations.

## Default Account Schema

Each source supports a variety of details, or attributes, about each user who has an account, such as their name, email address, manager name, and location.

The set of account attributes each source stores and how they're organized is known as the account's *schema*. To best represent your data, you can configure sources to use an account schema matching the one you use in the external connector. Refer to [Managing Source Account Schemas](<https://documentation.sailpoint.com/saas/help/accounts/schema.html>) for more information.

### Default Account ID

SailPoint requires that certain attributes remain in your configuration. These attributes are referred to as *account IDs*.

> [!CAUTION]
>
> Changing the attribute marked as the account ID after aggregating accounts can result in duplicate accounts being created. To avoid this, either reset the accounts on this source before editing the account ID attribute or edit the account ID attribute before aggregating accounts.
>
> To resolve issues caused by changing account IDs, reconfigure them to their default values.

The following table lists the default account IDs for this connector:

| Account ID | Schema Object Type |
| --- | --- |
| member\_id | Accounts |
| organization\_id | Groups |
| role\_id | Roles |

### Default Account Attributes

The Stytch connector supports the following default account schema attributes and customer configurable attributes. The attributes must be defined as strings if not specified.

| Attribute Name | Description |
| --- | --- |
| member\_id | Unique identifier for the organization member |
| organization\_id | Unique identifier of the organization the member belongs to |
| role\_id | Display the role of the user. |
| mfa\_phone\_number | Phone number used for multi-factor authentication |
| default\_mfa\_method | Default multi-factor authentication method for the member |
| created\_at | Timestamp when the member was created |
| password\_registrations | Password-based authentication registrations for the member |
| mfa\_enrolled | Indicates whether the member is enrolled in multi-factor authentication |
| totp\_registrations | Time-based One-Time Password registrations for the member |
| scim\_registrations | SCIM provisioning registrations for the member |
| saml\_registrations | SAML authentication registrations associated with the member |
| email\_address | Email address of the organization member |
| trusted\_metadata | Trusted metadata associated with the member |
| updated\_at | Timestamp when the member was last updated |
| is\_breakglass | Indicates whether the member has emergency breakglass access |
| sso\_registrations | Single Sign-On registrations associated with the member |
| webauthn\_registrations | WebAuthn authentication registrations for the member |
| name | Display name of the organization member |
| untrusted\_metadata | Untrusted metadata associated with the member |
| delete\_factor\_id | Identifier for the authentication factor to be deleted |
| oauth\_registrations | OAuth authentication registrations associated with the member |
| status | Current status of the organization member |
| is\_admin | Boolean Attributes tells whether the user is Admin or not |
| is\_locked | Determines if the user is locked |
| mfa\_phone\_number\_verified | Determines if the mfa phone number is verified |
| email\_address\_verified | Determines if the email address is verified |

## Default Entitlement Attributes

Entitlement attributes define the entitlements, such as groups or roles, that can be assigned to the managed system's user accounts. Refer to [Managing Entitlements](<https://documentation.sailpoint.com/saas/help/access/entitlements.html>) for more information.

> [!CAUTION]
>
> Changing the attribute marked as the Entitlement ID after aggregating accounts or entitlements can result in duplicate entitlements being created, or access profiles and roles breaking. To avoid this, edit the entitlement schema before performing any aggregations.

### Default Group Attributes

The Stytch connector also supports groups. The following attributes must be configured on the managed system and in the SailPoint source schema to manage groups.

| Attribute Name | Description |
| --- | --- |
| organization\_id | Unique identifier for the group |
| allowed\_auth\_methods | List of authentication methods explicitly allowed for the organization. |
| allowed\_first\_party\_connected\_apps | First-party applications explicitly allowed to connect to the organization. |
| allowed\_mfa\_methods | MFA methods that are permitted for user authentication. |
| allowed\_oauth\_tenants | Map of OAuth tenants that are explicitly allowed for authentication. |
| allowed\_third\_party\_connected\_apps | Third-party applications allowed to integrate with the organization. |
| auth\_methods | Policy that defines whether all or restricted authentication methods are allowed. |
| claimed\_email\_domains | Email domains that are claimed and verified by the organization. |
| created\_at | Timestamp when the organization record was created. |
| email\_allowed\_domains | Domains that are allowed for email-based login or registration. |
| email\_invites | Defines whether email invitations are allowed for onboarding users. |
| email\_jit\_provisioning | Policy controlling just-in-time user provisioning via email authentication. |
| first\_party\_connected\_apps\_allowed\_type | Rule defining whether all or selected first-party apps are allowed. |
| mfa\_methods | Policy defining whether all or restricted MFA methods are allowed. |
| mfa\_policy | Organization-level MFA requirement |
| oauth\_tenant\_jit\_provisioning | Controls JIT provisioning via OAuth tenant authentication. |
| organization\_external\_id | External system identifier for the organization. |
| organization\_logo\_url | URL for the organization’s logo image. |
| organization\_name | Display name of the organization. |
| organization\_slug | Short unique identifier for the organization used in URLs. |
| rbac\_email\_implicit\_role\_assignments | Rules for assigning roles automatically based on email domain |
| scim\_active\_connection | Currently active SCIM connection (if any). |
| scim\_active\_connections | List of all active SCIM provisioning connections. |
| sso\_active\_connections | List of configured and active SSO connections. |
| sso\_default\_connection\_id | Default SSO configuration used for login. |
| sso\_jit\_provisioning | Policy defining if JIT provisioning via SSO is allowed. |
| sso\_jit\_provisioning\_allowed\_connections | SSO connections allowed for JIT provisioning. |
| third\_party\_connected\_apps\_allowed\_type | Rule defining whether all or selected third-party apps are allowed. |
| trusted\_metadata | Custom metadata defined by the organization and trusted by the system. |
| updated\_at | Timestamp when the organization record was last updated. |

### Default Role Attributes

The Stytch connector supports roles. The following attributes must be configured on the managed system and in the SailPoint source schema to manage roles.

| Attribute Name | Description |
| --- | --- |
| role\_id | Unique identifier for the role |
| description | Description of the role and its purpose within the system |
| permissions\_actions | List of allowed actions for the specified resource (e.g., "`*`" means all actions) |
| permissions\_resource\_id | Identifier of the resource to which the actions apply |