Enterprise identity verification vendor

Custom IDV vendor

This document explains how to configure a custom IDV vendor as an identity provider (IdP) for your org. You can configure a custom IDV vendor as an IdP in your org by creating an account with the vendor, adding it as an IdP in Okta, and then testing the configuration. If you don't have a custom IDV vendor that you want to use, you can create your own IDV service and use this guide to add it as an IdP.

Note: IDV vendors are listed as IdPs in the Admin Console. This guide refers to the custom IDV vendor as an IDV vendor.

---

Learning outcomes

Configure a custom IDV vendor so that your user’s identities are verified when they enroll a new authenticator.

What you need

• Okta Integrator Free Plan org (opens new window)
• An IDV vendor that's integrated with Okta
• An account with the custom IDV vendor
• A test user account (opens new window) that you can use to enroll an authenticator
• A test group (opens new window) in your org that the test user is added to

---

What is an IDV vendor

IDV vendors work like IdPs, with some key differences. Vendors verify your user’s identities by requiring them to submit a proof of identity. The proof of identity matches a user’s digital identity against a trusted data source. For example, a user’s first name and family name can be matched against a picture of their driver’s license or passport. The vendor verifies the user submission against a data source and that evaluation is sent back to Okta.

IdPs authenticate users by verifying their digital credentials. The IdPs also maintain the digital credentials.

Because of its stricter verification, you might only use an IDV vendor for sensitive operations. For example, use an IDV flow when a user enrolls a new authenticator or resets their password.

Create an app at the IDV vendor

The process for creating an app with your IDV vendor varies depending on the vendor you choose. Regardless of the vendor configuration, you must complete the following steps:

1. Go to your custom IDV vendor.
2. Create a client app.
3. Create a client ID and client secret for the app.
4. Set your org URL as a redirect URI for the app and append /idp/identity-verification/callback. The redirect URI is the location where the custom IDV vendor sends the verification response.
   1. For example, if your Okta subdomain is called company, then the URL would be: https://company.okta.com/idp/identity-verification/callback If you’ve configured a custom domain in your Okta org, use that value to construct your redirect URI, such as https://login.company.com/idp/identity-verification/callback.

IDV vendors can learn how to integrate with Okta by reviewing Integrate Okta with identity verification vendors.

After creating the app with your IDV vendor, you can create the IdP integration in your org.

Note: Your IDV vendor might have other configuration settings. Refer to their documentation for more information about other configuration settings.

Create the IDV vendor in Okta

Use the IdP API (opens new window) to add your custom IDV vendor in Okta. Create your own POST request body or copy the example request and input your values.

Note: To add a custom IDV vendor using the Admin Console, see Add an Identity Verification vendor as Identity Provider (opens new window).

1. Set the following request body parameters:

   • Enter a value for name.
   • Set type to IDV_STANDARD.
   • Set ID_PROOFING as the protocol type.
   • Use the Client ID and Client Secret values from the previous section as the client_id and client_secret values.
   • Use the URLs that your IDV vendor provided in the following parameters:
     • issuer.url: The Issuer URL that your IDV vendor provided.
     • endpoints.par.url: The PAR request URL that your IDV vendor provided.
     • endpoints.authorization.url: The Authorize URL that your IDV vendor provided.
     • endpoints.token.url: The Token URL that your IDV vendor provided.
     • endpoints.jwks.url: The JWKS URL that your IDV vendor provided.
   • Set the properties.idvMetadata object values:
     • vendorDisplayName: The Vendor name that your IDV vendor provided.
     • termsOfUse: The End user license agreement (EULA) URL that your IDV vendor provided.
     • privacyPolicy: The Privacy policy URL that your IDV vendor provided.
   • Set the scopes array to include the profile, identity_assurance, and openid scopes.
     • profile: This scope allows the IDV vendor to request access to basic user profile information from Okta.
     • identity_assurance: This scope requests access to the verified_claims object so that the IDV vendor can send and receive information about the level of assurance of the IDV flow.
     • openid: This scope is required to make the request an OpenID Connect (OIDC) request.

2. Send the POST /api/v1/idps request.

3. After you create the IDV vendor, copy the value of id from the response body and paste it into a text editor. Use it in the next section.

Example request

{
  "type": "IDV_STANDARD",
  "name": "Custom IDV",
  "protocol": {
    "type": "ID_PROOFING",
    "endpoints": {
      "par": {
        "url": "https://idv.example.com/par",
        "binding": "HTTP-REDIRECT"
      },
      "authorization": {
        "url": "https://idv.example.com/authorize",
        "binding": "HTTP-REDIRECT"
      },
      "token": {
        "url": "https://idv.example.com/token",
        "binding": "HTTP-POST"
      },
      "jwks": {
        "url": "https://idv.example.com/jwks",
        "binding": "HTTP-REDIRECT"
      }
    },
    "issuer": {
      "url": "https://idv.example.com"
    },
    "scopes": [
      "profile",
      "identity_assurance",
      "openid"
    ],
    "credentials": {
      "client": {
        "client_id": "your-client-id",
        "client_secret": "your-client-secret"
      }
    }
  },
  "policy": {
    "provisioning": {
      "action": "DISABLED",
      "profileMaster": false,
      "groups": null
    },
    "accountLink": {
      "filter": null,
      "action": "AUTO"
    },
    "subject": {
      "userNameTemplate": {
        "template": "source.userName"
      },
      "filter": null,
      "matchType": "USERNAME",
      "matchAttribute": null
    },
    "maxClockSkew": 0
  },
  "properties": {
    "idvMetadata": {
      "vendorDisplayName": "Custom IDV",
      "termsOfUse": "https://idv.example.com/terms",
      "privacyPolicy": "https://idv.example.com/privacy"
    }
  }
}

Example response

{
  "id": "0oa2pstvoFV4GYCw30g5",
  "name": "Custom IDV IdP",
  "status": "ACTIVE",
  "created": "2025-01-15T20:54:04.000Z",
  "lastUpdated": "2025-01-15T20:54:05.000Z",
  "protocol": {
    "type": "ID_PROOFING",
    "endpoints": {
      "par": {
        "url": "https://idv.example.com/par",
        "binding": "HTTP-REDIRECT"
      },
      "authorization": {
        "url": "https://idv.example.com/authorize",
        "binding": "HTTP-REDIRECT"
      },
      "token": {
        "url": "https://idv.example.com/token",
        "binding": "HTTP-POST"
      },
      "jwks": {
        "url": "https://idv.example.com/jwks",
        "binding": "HTTP-REDIRECT"
      },
      "issuer": {
        "url": "https://idv.example.com"
      },
      "scopes": [
        "openid",
        "profile",
        "identity_assurance"
      ],
      "credentials": {
        "client": {
          "client_id": "your-client-id",
          "client_secret": "your-client-secret"
        }
      },
      "policy": {
        "provisioning": {
          "action": "DISABLED",
          "profileMaster": false,
          "groups": null
        },
        "subject": {
          "userNameTemplate": {
            "template": "source.userName",
            "filter": null,
            "matchType": "USERNAME",
            "matchAttribute": null
          },
          "maxClockSkew": 0,
          "properties": {
            "idvMetadata": {
              "vendorDisplayName": "Custom IDV",
              "termsOfUse": "https://idv.example.com/terms",
              "privacyPolicy": "https://idv.example.com/privacy"
            }
          }
        },
        "type": "IDV_STANDARD",
        "_links": {
          "users": {
            "href": "https://{yourOktaDomain}/api/v1/idps/0oa2pstvoFV4GYCw30g5/users",
            "hints": {
              "allow": [
                "GET"
              ]
            }
          },
          "deactivate": {
            "href": "https://{yourOktaDomain}/api/v1/idps/0oa2pstvoFV4GYCw30g5/lifecycle/deactivate",
            "hints": {
              "allow": [
                "POST"
              ]
            }
          }
        }
      }
    }
  }
}

Map profile attributes from Okta to your IDV vendor

After you've created the IDV vendor in Okta, you can map other profile attributes from your user directory to attributes in your IDV vendor. Okta sends the givenName and familyName attributes by default. You can map other attributes as needed. See Map profile attributes from Okta to an identity verification vendor (opens new window).

Create an Okta account management policy rule

Use the Policies API (opens new window) to create a rule that requires your custom IDV vendor to verify users when they enroll a new authenticator. Create your own POST request body or copy the example request and input your values.

Ensure that you’ve created a group for users who you want to verify with your custom IDV vendor. For example, create a group called "Custom IDV test group".

Note: To add a rule using the Admin Console, see Edit the Okta account management policy (opens new window).

1. Retrieve the Okta account management policy ID. Use the Okta account management policy id as the policyId value in your POST request to create the IDV rule.

2. Set the following request body parameters for the new IDV rule that you want to create:

   • Provide a name value.
   • Use the Okta account management policy id as the policyId value.
   • Set the group ID. Use the List all groups call (opens new window) to find the id for the test group.
   • Set the verificationMethod type to ID_PROOFING.
   • Set the verificationMethod > id as the ID of the custom IDV vendor IdP that you created in the previous section.
   • Set appSignOn access value to ALLOW.
   • Use the following Okta Expression Language object:

       "elCondition": {
           "condition": "accessRequest.operation == 'enroll'"
       }
   

   This expression requires users to verify their identity with the IDV vendor when they enroll a new authenticator.

3. Send the POST /api/v1/policies/{policyId}/rules request.

Okta account management policy rule example request

{
    "name": "Require IDV for authenticator enrollment",
    "priority": 1,
    "type": "ACCESS_POLICY",
    "system": false,
    "conditions": {
        "people": {
            "groups": {
                "include":
                    ["{groupId}"]
            }
        },
        "network": {
            "connection": "ANYWHERE"
        },
        "riskScore": {
            "level": "ANY"
        },
        "elCondition": {
            "condition": "accessRequest.operation == 'enroll'"
        },
        "userType": {
            "include": [],
            "exclude": []
        }
    },
    "actions": {
        "appSignOn": {
            "access": "ALLOW",
            "verificationMethod": {
                "id": "{IDVId}",
                "type": "ID_PROOFING"
            }
        }
    }
}

Example response

{
    "id": "ruleId",
    "status": "ACTIVE",
    "name": "Require IDV for authenticator enrollment",
    "priority": 1,
    "created": "2024-11-14T21:16:55.000Z",
    "lastUpdated": "2024-11-14T21:16:55.000Z",
    "system": false,
    "conditions": {
        "people": {
            "users": {
                "exclude": []
            },
            "groups": {
                "include": [
                    {"groupId"}
                ]
            }
        },
        "network": {
            "connection": "ANYWHERE"
        },
        "riskScore": {
            "level": "ANY"
        },
        "elCondition": {
            "condition": "accessRequest.operation == 'enroll'"
        },
        "userType": {
            "include": [],
            "exclude": []
        }
    },
    "actions": {
        "appSignOn": {
            "access": "ALLOW",
            "verificationMethod": {
                "id": {"IDVId"},
                "type": "ID_PROOFING"
            }
        }
    },
    "_links": {
        "self": {
            "href": "https://{yourOktadomain}/api/v1/policies/rstjqw4t47yn9lXUK5d7/rules/rull5mrtqkAVfIyWT5d7",
            "hints": {
                "allow": [
                    "GET",
                    "PUT",
                    "DELETE"
                ]
            }
        },
        "deactivate": {
            "href": "https://{yourOktadomain}/api/v1/policies/rstjqw4t47yn9lXUK5d7/rules/rull5mrtqkAVfIyWT5d7/lifecycle/deactivate",
            "hints": {
                "allow": [
                    "POST"
                ]
            }
        }
    },
    "type": "ACCESS_POLICY"
}

Test the integration

After you've configured your custom IDV vendor and created the Okta account management policy rule, you can test the integration.

Testing the integration can depend on your IDV vendor. Depending on your vendor, you might be able to use a sandbox environment to complete the verification. Refer to your IDV vendor's documentation for more information about testing the integration.

However, there's a simple way to test if the Okta account management policy and IDV vendor are set up correctly in your org. Try to enroll an authenticator using your test user. If your IDV vendor and policy are set up correctly, that user is prompted to verify their identity with the IDV vendor before they can complete the enrollment.

Note: Your user may not be able to complete the IDV flow if their information doesn't match the verifiable information required by your IDV vendor. Review the System Log (opens new window) if you encounter errors when testing the IDV flow. See Identity verification events for information about IDV events in the System Log.

Alternate use cases

You can use your IDV vendor to verify your user identities in different scenarios. Use the following Okta Expression Language expressions for different scenarios.

Note: You can use the Okta account management policy rule without any expression. If you don't use any expression in the rule then your user is prompted to verify their identity when at least one of the following events occurs:

• They enroll or unenroll authenticators.

• They edit their personal information in their Settings.

• They reset their password in Settings or in the Sign-in widget.

• They unlock their account.

Verify user identity only when they enroll an authenticator

accessRequest.operation == 'enroll'

Verify user identity only when they reset their password

accessRequest.authenticator.key == 'okta_password' && accessRequest.operation == 'recover'

Verify user identity only when they enroll phishing-resistant authenticators

{
  'okta_verify',
  'webauthn',
  'smart_card_idp',
  'yubikey_token'
}.contains(accessRequest.authenticator.key) &&
accessRequest.operation == 'enroll'

Troubleshooting

When you test the integration, if you’re not redirected to the IDV flow, review the following areas:

• Review the user and group that you created. Ensure that you’ve set the correct group ID when you create the Okta account management policy rule.

• Review the Okta account management policy rule. Ensure that you’ve added the correct Okta Expression Language expression and that the verificationMethod type is set to ID_PROOFING.

• Ensure that your user has the authenticators that they're allowed to enroll.