/ /

External identity provider setup

Configure DevRev to use an external identity provider (IdP) for single sign-on (SSO) via SAML 2.0 or OIDC.

DevRev can be configured to use external identity providers for SSO. Follow the instructions for your organization's provider.

Before you begin

To register DevRev as a SAML 2.0 application, you need the slug for your workspace.

Go to Settings > General in the DevRev app. The slug is displayed under your organization name.

If you prefer the API, or if you need the dev_oid for the connection name, run the following command using a personal access token (PAT) with admin permissions:

curl --location --request GET 'https://api.devrev.ai/internal/dev-orgs.self.get' \
--header 'Authorization: <your PAT>'

📝 Note: The dev_oid is returned in the response. Depending on your account configuration, it may appear in the display_id or id field—check both fields in your response and use the value that matches the DON- prefix format.

Ensure the connection_name combines the dev_oid prefix with a custom string and matches the following regex pattern:

^[a-zA-Z0-9](-[a-zA-Z0-9]|[a-zA-Z0-9])*$

This means it must:

  • Start with an alphanumeric character.

  • Contain alphanumeric characters or hyphens, without consecutive or trailing hyphens.

  • Be unique within your organization.

  • Follow the pattern: <dev_oid>-<CUSTOM-STRING>.

The API call to create the connection fails if this pattern is not followed.

Register DevRev as a service provider

You can register DevRev as a service provider in any identity provider that supports SAML 2.0 or OpenID Connect (OIDC).

Azure AD

  1. Log in to Azure Active Directory and select Enterprise applications > + New application.

  2. Search for "Azure AD SAML Toolkit" in the Browse Azure AD Gallery and select it.

  3. Enter DevRev as the name and click Create.

  4. Select Single sign-on > SAML.

  5. Edit the Basic SAML Configuration and enter the following parameters.

    • Identifier (Entity ID): urn:auth0:tf-devrev-prod:<connection_name>

    • Reply URL (Assertion Consumer Service URL): https://auth.devrev.ai/login/callback?connection=<connection_name>

    • Sign on URL: https://app.devrev.ai/<DEV_ORG_SLUG>

    đź“ť Note: The <connection_name> must be identical in both parameters and follow the naming pattern described in Before you begin.

  6. Go to SAML Certificates and save the App Federation Metadata URL.

  7. In the Azure portal, open the DevRev enterprise application, go to Users and Groups, and assign the users who need access.

Google Workspace

  1. Log in to Google Workspace as an admin.

  2. Select Apps > Web and mobile apps > Add app > Add custom SAML app.

  3. Enter DevRev as the name of the app.

  4. On the next screen, select Download IdP metadata, then click Continue.

  5. Enter the following parameters.

    • ACS URL: https://auth.devrev.ai/login/callback?connection=<connection_name>

    • Entity ID: urn:auth0:tf-devrev-prod:<connection_name>

    • Name ID format: Email

    • Name ID: Basic Information > Primary Email

    đź“ť Note: The <connection_name> must be identical in both parameters and follow the naming pattern described in Before you begin.

JumpCloud

  1. Log in to the JumpCloud Administrator Console and go to User Authentication > SSO > + Add New Application.

  2. Search for "Auth0" and click Configure.

  3. Enter DevRev in General Info > Display Label.

  4. Enter the following parameters.

    • YOURTENANTDOMAIN: https://auth.devrev.ai/login/callback?connection=<connection_name>

    • TEAMNAME: <DEV_ORG_SLUG>

  5. Click Activate, then click Continue in the confirmation window.

  6. Click Download Certificate in the top left of the window.

  7. Find Auth0 in the application list on the SSO page and click anywhere in the row to reopen the application configuration panel.

  8. Select the SSO tab and copy the IdP URL.

Leave the Admin Portal open.

Okta

  1. Log in to Okta as an admin and go to Applications > Applications > Create App Integration > SAML 2.0.

  2. Complete the General Settings.

  3. Enter the following parameters.

    • Single sign-on URL: https://auth.devrev.ai/login/callback?connection=<connection_name>

    • Audience URI (SP Entity ID): urn:auth0:tf-devrev-prod:<connection_name>

    • Name ID format: EmailAddress

    • Application username: Email

    • Feedback: I'm an Okta customer adding an internal app

    • App type: This is an internal app that we have created

    đź“ť Note: The Feedback and App type fields are Okta's own classification prompts for the integration wizard. Select these values to indicate that DevRev is an internally managed app integration in your Okta org. The <connection_name> must be identical in both URL parameters and follow the naming pattern described in Before you begin.

  4. After saving, go to Sign On > Settings > SAML 2.0 and copy the metadata URL. You will use this URL when creating the authentication connection in the next section.

Configure DevRev to use your identity provider

After registering DevRev as an application in your identity provider, create an authentication connection in DevRev that links to your identity provider. This connection enables DevRev to authenticate users through your external identity provider.

Before proceeding, ensure you have the following:

  • A personal access token (PAT) with admin permissions.

  • Connection details from your identity provider setup.

  • Your dev_oid and organization slug from the previous steps.

Create the authentication connection

An authentication connection is a configuration object that tells DevRev how to communicate with your identity provider. Use the auth connections create API to create this connection.

Choose the appropriate protocol based on your identity provider.

SAML 2.0

For SAML-based identity providers (Azure AD, Okta, etc.):

curl --location --request POST 'https://api.devrev.ai/dev-orgs.auth-connections.create' \
--header 'Authorization: Bearer <your PAT>' \
--header 'Content-Type: application/json' \
--data-raw '{
  "type": "samlp",
  "sign_in_endpoint": "<sign_in_endpoint>",
  "signing_cert": "<signing_cert>",
  "connection_name": "<connection_name>",
  "display_name": "<display_name>"
}'

Expected successful response:

{
  "auth_connection": {
    "id": "con_12345678",
    "display_name": "<display_name>",
    "enabled": false,
    "type": "samlp",
    "sign_in_endpoint": "<sign_in_endpoint>",
    "connection_name": "<connection_name>"
  }
}

OpenID Connect

For OIDC-based identity providers:

curl --location --request POST 'https://api.devrev.ai/dev-orgs.auth-connections.create' \
--header 'Authorization: Bearer <your PAT>' \
--header 'Content-Type: application/json' \
--data-raw '{
    "display_name": "<display_name>",
    "type": "oidc",
    "client_id": "<client_id>",
    "client_secret": "<client_secret>",
    "issuer": "<issuer>"
}'

Expected successful response:

{
  "auth_connection": {
    "id": "con_12345678",
    "display_name": "<display_name>",
    "enabled": false,
    "type": "oidc",
    "client_id": "<client_id>",
    "issuer": "<issuer>"
  }
}

đź“ť Note:

  • The connection_name must follow the naming pattern described in the parameter reference below.

  • Save the id field from the response—you need it for the next step.

  • The connection is created with enabled: false by default for security.

Enable the authentication connection

After successfully creating the connection, enable it using the connection ID from the previous response:

curl --location --request POST 'https://api.devrev.ai/dev-orgs.auth-connections.toggle' \
--header 'Authorization: Bearer <your PAT>' \
--header 'Content-Type: application/json' \
--data-raw '{
  "id": "<CONNECTION_ID>",
  "toggle": "enable"
}'

Expected successful response:

{}

Test and verify the setup

  1. Go to https://app.devrev.ai/<DEV_ORG_SLUG> and confirm that a new SSO login option appears with your identity provider's name.

  2. Sign in with a test user account that is assigned to the DevRev application in your identity provider, complete the authentication flow, and verify the user lands in DevRev successfully.

  3. Attempt to sign in with a user who is not assigned to the DevRev application and confirm the attempt is rejected.

  4. Test logout and verify that session timeout behavior matches your identity provider's session policy.

đź’ˇ Tip: Always validate with a test account before rolling out SSO to all users. Test both successful and failed authentication scenarios before disabling alternative login methods.

Manage authentication methods

After enabling SSO, you can disable other authentication methods to enforce SSO-only login across your workspace. This ensures all users authenticate through your organization's identity provider.

Disable Google OAuth. If users previously signed in with Google OAuth, retrieve the Google OAuth connection ID and then disable it:

curl --location --request GET 'https://api.devrev.ai/dev-orgs.auth-connections.list' \
--header 'Authorization: Bearer <your PAT>'

Locate the Google OAuth entry in the response and note its id field, then disable it:

curl --location --request POST 'https://api.devrev.ai/dev-orgs.auth-connections.toggle' \
--header 'Authorization: Bearer <your PAT>' \
--header 'Content-Type: application/json' \
--data-raw '{
  "id": "<GOOGLE_OAUTH_CONNECTION_ID>",
  "toggle": "disable"
}'

⚠️ Warning: Confirm that SSO is working correctly and that at least one admin can authenticate via SSO before disabling any alternative login method. Users who were previously signing in with email/password or social login are not automatically migrated—they must sign in through the new SSO connection on their next login attempt. Users who cannot authenticate via SSO will lose access until the issue is resolved or an alternative method is re-enabled.

Delete a misconfigured connection. If a connection was created with incorrect parameters, list all connections to identify the target ID, then delete it:

curl --location --request POST 'https://api.devrev.ai/dev-orgs.auth-connections.delete' \
--header 'Authorization: Bearer <your PAT>' \
--header 'Content-Type: application/json' \
--data-raw '{
  "id": "<CONNECTION_ID>"
}'

Recreate the connection using the SAML 2.0 or OpenID Connect procedure above with the corrected parameters after deletion.

SCIM provisioning. Once SSO is enabled, many enterprise workspaces proceed to configure SCIM-based user provisioning to automate user lifecycle management. See the SCIM with Okta guide for setup instructions.

JIT provisioning

Just-in-Time (JIT) provisioning automatically creates a DevRev user account the first time a user successfully authenticates through an SSO connection, without requiring a prior invitation. This means any user who exists in your identity provider and is assigned to the DevRev application can gain access to your workspace on first login.

JIT provisioning is enabled by default for SSO connections in DevRev. If your organization requires tighter control over who can access the workspace—for example, if not all identity provider users should have DevRev access—use your identity provider's application assignment settings to restrict which users and groups are permitted to authenticate. Users who are not assigned to the DevRev application in the identity provider are blocked at the IdP level before JIT provisioning can create an account.

For fully automated user lifecycle management including deprovisioning, configure SCIM provisioning in addition to SSO.

IDP-initiated SSO

DevRev supports SP-initiated SSO, where users always start the authentication process from DevRev. IDP-initiated SSO, where users start from the identity provider's portal, is not supported.

A practical workaround is to bookmark your DevRev workspace URL (https://app.devrev.ai/<DEV_ORG_SLUG>) in your identity provider's application portal. With only the SSO auth connection enabled, the experience is nearly seamless—clicking the bookmark redirects users through the SP-initiated flow automatically.

For SSO configuration scoped to the customer-facing portal rather than the DevRev workspace, see the federated portal SSO documentation, which covers a distinct use case.

Parameter reference

  • <your PAT>: Personal Access Token with admin permissions.

  • <dev_oid>: Your DevRev organization ID, returned from the initial API call.

  • <CUSTOM-STRING>: A custom identifier you choose; must be consistent across all configurations.

  • <connection_name>: A unique identifier for your connection; must follow the required naming pattern.

  • <display_name>: A human-readable name shown on the login page.

  • <DEV_ORG_SLUG>: Your DevRev organization slug.

  • <CONNECTION_ID>: The id value returned when the connection is created.

Troubleshooting

  • Issue: The connection_name is rejected with a validation error.

    Solution: The connection_name must match the required naming pattern (alphanumeric characters and hyphens only, no spaces or special characters, and must begin with a letter). Verify the value against the pattern described in the parameter reference and resubmit.

  • Issue: SAML certificate is rejected or signature validation fails.

    Solution: Ensure the certificate is in PEM format, includes the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- headers, and contains no extra whitespace or line-break inconsistencies. Re-export the certificate from your identity provider if necessary.

  • Issue: Users receive an "access denied" or "user not assigned" error from the identity provider during login.

    Solution: In your identity provider's admin console, confirm that the user or the user's group is explicitly assigned to the DevRev application. In Okta, check Applications > DevRev > Assignments. In Azure AD, check Enterprise Applications > DevRev > Users and groups. In Google Workspace, verify the app is enabled for the user's organizational unit.

  • Issue: Authentication endpoint errors are returned for SAML connections.

    Solution: Verify that the sign_in_endpoint URL is publicly accessible and returns a valid SAML response. Check that the entity ID and ACS URL in your identity provider match the values provided during connection creation.

  • Issue: OIDC login fails with a token or issuer validation error.

    Solution: Confirm that the issuer URL exactly matches the value in your identity provider's OpenID configuration document (typically available at <issuer>/.well-known/openid-configuration). Verify that the client_id and client_secret are correct and that the redirect URI registered in the identity provider matches DevRev's callback URL.

  • Issue: SSO login option does not appear on the workspace login page after enabling the connection.

    Solution: Confirm the connection was enabled using the toggle API in the Enable the authentication connection section and that the response was an empty {} with a 200 status. Re-run the list call (dev-orgs.auth-connections.list) to verify the connection shows "enabled": true.

For issues not covered here, contact the DevRev customer success team with your connection ID and the full error message.

Was this article helpful?