Instructions for

Submit an integration with the OIN Wizard

Learn how to submit an OIDC, SAML 2.0, or SCIM 2.0 integration to the Okta Integration Network (OIN) using the OIN Wizard.

What you need

An Okta Integrator Free Plan org (opens new window). The OIN Wizard is only available in Integrator Free Plan orgs.
An admin user in the Integrator Free Plan org with either the super admin or the app and org admin roles
A functional integration based on the Build a Single Sign-On integration or Build a SCIM provisioning integration guide
Google Chrome browser with the Okta Browser Plugin installed (see OIN Wizard requirements)
The various items necessary for submission in accordance with the OIN submission requirements

Overview

Okta provides you with a seamless experience to integrate and submit your app for publication in the Okta Integration Network (OIN) (opens new window). When you obtain an Integrator Free Plan org (opens new window), you can use it as a sandbox to integrate your app with Okta and explore more Okta features. When you decide to publish your integration to the OIN, you can use the same Integrator Free Plan org to submit your integration using the OIN Wizard.

The OIN Wizard is a full-service tool in the Admin Console for you to do the following:

Provide all your integration submission details.
Generate an app instance in your org for testing:
- Test your SSO integration with the OIN Submission Tester.
- Test your SCIM integration with manual test cases and Runscope test suites.
Submit your integration directly to the OIN team when you're satisfied with your test results.
Monitor the status of your submissions through the Your OIN Integrations dashboard.
Edit published integrations and resubmit them to the OIN.

The OIN team verifies your submitted integration before they publish it in the OIN catalog (opens new window).

Note: Traditional SPA and mobile apps integrate with Okta using an OIDC flow that authenticates by exchanging and storing tokens on the client. They rely on client-side authentication and can't be added to the OIN Wizard directly. However, SaaS app stacks with SPA or mobile components can be included in the OIN Wizard if a backend server handles the authentication. See the Enterprise-Ready workshop (opens new window) for more information on authenticating SaaS apps with OpenID Connect.

Protocols supported

This guide covers submissions that use the following protocols:

Notes:

SWA app integrations are no longer accepted for publication in the OIN catalog. However, the OIN team still maintains existing SWA apps.

There are protocol-specific limitations on integrations in the OIN. See OIN limitations.

Start a submission

Review the OIN submission requirements before you start your submission. There are artifacts and technical details that you need to provide during the submission process.

Note: As a best practice, add two or three extra admin users in your Okta org to manage the integration. This ensures that your team can access the integration for updates in the future. See Add users manually (opens new window) and ensure that the app and org admin roles are assigned to your admin users. The super admin role also provides the same access, but Okta recommends limiting super admin role assignments.

Start your integration submission for OIN publication:

Sign in to your Integrator Free Plan org as a user with either the super admin (SUPER_ADMIN) role, or the app (APP_ADMIN) and org (ORG_ADMIN) admin roles (opens new window).

Note: Submit your integration from an Okta account that has your company domain in the email address. You can't use an account with a personal email address. The OIN team doesn't review submissions from personal email accounts.
Go to Applications > Your OIN Integrations in the Admin Console.

Note: If you only want to test an existing submission, see Navigate directly to test your integration.
Click Build new OIN integration. The OIN Wizard appears.
Select the protocols that your integration supports from the Select protocol section.

Note: The instructions on this page are for the

Security Assertion Markup Language (SAML)
protocol.
If you want to change the protocol instructions on this page, select the protocol you want from the Instructions for dropdown list on the right.
Click Configure your integration.

Configure your integration

Continue with the OIN Wizard and configure your integration:

OIN catalog properties

In the OIN catalog properties section, specify the following OIN catalog information:

Property	Description
Display name `*`	Provide a name for your integration. This is the main title used for your integration in the OIN. The maximum field length is 64 characters.
Description `*`	Give a general description of your app and the benefits of this integration to your customers. See App description guidelines.
Logo `*`	Upload a PNG, JPG, or GIF file of a logo to accompany your integration in the catalog. The logo file must be less than one MB. See Logo guidelines.
Use Cases	Add optional use case categories that apply to your integration: Automation Centralized Logging Directory and HR Sync Identity Governance and Administration (IGA) Identity Verification Multifactor Authentication (MFA) Zero Trust You can select up to three optional use cases. Default use cases are assigned to your integration based on supported features. See Use case guidelines.

* Required properties

Integration variables

Configure integration variables if your URLs are dynamic for each tenant. The variables are for your customer admins to add their specific tenant values during installation. See Dynamic properties with Okta Expression Language.

In the Integration variables section, specify the name and label for each variable:

Property	Description
Label `*`	A descriptive name for the dynamic variable that admins see when they install your app integration. For example: `Subdomain`
Name `*`	Specify the variable name. This variable name is used to construct the dynamic URL. It's hidden from admins and is only passed to your external app. String is the only variable type supported. Note: Use alphanumeric lowercase and underscore characters for the variable name field. The first character must be a letter and the maximum field length is 1024 characters. For example: `subdomain_div1`

Property

Description

Label * A descriptive name for the dynamic variable that admins see when they install your app integration. For example: Subdomain

Name * Specify the variable name. This variable name is used to construct the dynamic URL. It's hidden from admins and is only passed to your external app.
String is the only variable type supported.
Note: Use alphanumeric lowercase and underscore characters for the variable name field. The first character must be a letter and the maximum field length is 1024 characters. For example: subdomain_div1

* This section is optional, but if you specify a variable, both Label and Name properties are required.

Click + Add another to add another variable. You can add up to eight variables.

Note: Apps that are migrated from the OIN Manager and that have more than eight variables can retain those variables, but you can't add new ones. However, you can update or delete the existing variables.
If you need to delete a variable, click the delete icon () next to it.

SAML
properties

Note: The instructions on this page are for the

Security Assertion Markup Language (SAML)
protocol.
If you want to change the protocol instructions on this page, select the protocol from the Instructions for dropdown list on the right.

Continue with the OIN Wizard and configure your protocol settings:

Specify the following protocol properties in the

SAML

properties section:

Property	Description
Default ACS URL `*`	Specify the default Assertion Consumer Service (ACS) URL. If you're using a per tenant design, include the variable names that you created in your URL. For example: `https://${org.subdomain}.example.org/strawberry/login`. See Dynamic properties with Okta Expression Language. All static URLs must begin with `https://` and be complete. For URL expressions, you can use any valid format. The maximum field length is 1024 characters.
	Provide an indexed ACS URL if your integration supports multiple ACS URLs where Okta can send the SAML response. Adding an ACS URL is optional, but if you add one, both properties are required: ACS URL ``: Specify another ACS URL. See Dynamic properties with Okta Expression Language. The maximum field length is 1024 characters. Index* ``: Specify the index for the corresponding ACS URL. You can't reuse the same index in the list, and the index must be an integer 0–65535. Click + Add another* to add more URLs.
Entity ID / audience restriction `*`	Specify your SAML entity ID or the audience restriction.
Attribute statements	Specify the attribute name and values of your claim. Adding a claim is optional, but if you add one, both properties are required. Attribute name ``: Specify the claim name. Values* ``: Specify a comma-separated list of values for the claim. Note: Ensure that you use valid user profile properties when referencing attribute values in EL expressions. The system rejects any invalid user EL expressions and attributes that aren't included in the allowlist. The acceptable value for Okta username is `${user.userName}`. The rest of the attributes from the Okta user profile should follow the format `user.<attributeVariable>` and the Application user profile attributes should follow the format `appuser.<attributeVariable>`. Click + Add another* to add another claim.
Group attributes	Specify your group attribute statements if your app supports receiving SAML group attribute statements. See Define attribute statements (opens new window) and Define group attribute statements (opens new window) for details on configuring attribute statements. Click + Add another to add more statements.
Configuration guide URL `*`	Specify the URL link to your customer-facing instructions on how to configure SSO between Okta and your app with SAML. See Customer configuration document guidelines.

* Required properties

Click Get started with testing to save your edits and move to the testing section, where you need to enter your integration test details.

Dynamic properties with Okta Expression Language

The OIN Wizard supports Okta Expression Language to generate dynamic properties, such as URLs or URIs, based on your customer tenant. You can specify dynamic strings for your

properties in the OIN Wizard:

Add your integration variables in the OIN Wizard. These variables become fields for customers to enter during your OIN integration installation to identify their tenant.
Use the integration variables with Expression Language format in your

SAML
property definitions for dynamic values based on customer information.

For example, if you have a SAML configuration variable called subdomain, then you can set your ACS URL string to https://${org.subdomain}.example.org/strawberry/login. When your customer sets their subdomain variable value to berryfarm, then https://berryfarm.example.org/strawberry/login is their ACS URL.

Note: A variable can include a complete URL (for example, https://example.com). This enables you to use global variables, such as org.baseURL.

The following are Expression Language specifics for SAML properties:

SAML integration variables you define in the OIN Wizard are considered Organization properties and have the org. prefix when you reference them in Expression Language. For example, if your integration variable name is subdomain, then you can reference that variable with org.subdomain.
SAML properties support Expression Language conditional expressions and evaluates everything between ${ and }. For example, the following is an expression for the ACS URL property:
```
${empty org.baseUrl ? 'https://app.mydomain.com' : org.baseUrl}
```

SAML properties don't support Expression Language String functions (opens new window). Use JSTL functions (opens new window) instead. For example:

${fn:substringAfter(org.base_url, '//')}

${fn:substringBefore(user.userName, '@')}@example.com

https://${fn:endsWith(org.site_url, 'host1.com') ? 'host1.com' : fn:endsWith(org.site_url, 'host2.com') ? 'host2.com' : '.host.com'}/sso/saml

https://${fn:contains(org.environment, 'production') ? 'productiondomain.com' : 'previewdomain.com'}/sso/saml

Enter test information

From the OIN Wizard Test your integration page, specify the information that's required for testing your integration. The OIN team uses this information to verify your integration after submission.

Test information for Okta review

A dedicated test admin account in your app is required for Okta integration testing. This test account needs to be active during the submission review period for Okta to test and troubleshoot your integration. Ensure that the test admin account has:

Privileges to configure admin settings in your test app
Privileges to administer test users in your test app
Credentials to access the SCIM server for SCIM integrations

After your integration is verified, Okta automatically deletes test account credentials 30 days after your app is published in the OIN Wizard. To resubmit your app after this period, create a new test account and provide the required information.

See Test account guidelines.

Note: This admin account is in your app and not an account in Okta.

In the Testing information for Okta review section, specify the following Test account details:

Property	Description
Account URL `*`	A static URL to sign in to your app. An OIN analyst goes to this URL and uses the account credentials you provide in the subsequent fields to sign in to your app.
Username `*`	The username for your test admin account. The OIN analyst signs in with this username to execute test cases. The preferred account username is `isvtest@okta.com`.
Password `*`	The password for your test admin account
Support contact `*`	Provide an email for Okta to contact your company about your integration. This email isn't exposed in the OIN catalogs or to your customers. Okta uses this email to contact your company for integration status updates, issues during the QA testing phase, or for ongoing maintenance. See Escalation support contact in the customer support-contact guidelines.
Testing instructions	Include information that the OIN team needs to know about your integration for testing (such as the admin account or the testing configuration). You can also provide instructions on how to add test user accounts. For a SCIM integration, specify how to access the SCIM server for testing. Provide the SCIM server base URL and credentials for the OIN team to conduct QA testing. You can include instructions on obtaining SCIM credentials (API token or OAuth 2.0 properties) from your admin app.

* Required properties

SAML
tests

In the SAML tests section, specify the following sign-in flow details:

Property		Description
Supported sign-in flows		Indicate which sign-in flow your integration supports. You must select at least one of the following flows.
	IdP	Sign-in flow is initiated from the Okta End-User Dashboard.
	SP	Sign-in flow is initiated from your app sign-in page.
Supports Just-In-Time provisioning? `*`		Indicate if your integration supports Just-In-Time (JIT) provisioning. With JIT provisioning, you can use a SAML assertion to create users the first time they try to sign in. This eliminates the need to create user accounts in advance.
	Yes	Your integration supports JIT.
	No	Your integration doesn't support JIT.
SP Initiate URL		Specify the URL for SP-initiated sign-in flows. This URL is required for the SP flow. The maximum URL length is 512 characters.
SP Initiate flow description		Provide instructions on how to sign in to your app using the SP-initiated flow. The maximum description length is 2048 characters. This field is required for the SP flow.

* Required properties

Click Test your integration to save your test information and begin the integration testing phase.

Test your integration

The OIN Wizard journey includes the Test integration experience page to help you configure and test your integration within the same org before submission. These are the tasks that you need to complete:

Generate instances for testing. You need to create an app integration instance to test each protocol that your integration supports.
- For an SSO integration, configure SSO and assign test users on the test instance.
- For a SCIM integration, configure provisioning and map user profile attributes on the test instance.
Test your integration.
- For an SSO integration, test the required flows in the OIN Submission Tester with your generated test instance. Fix any test failures from the OIN Submission Tester, then regenerate the test instance (if necessary) and retest.
- For a SCIM integration, execute the Runscope CRUD tests and the Okta manual integration tests with your generated test instance.
Submit your integration after all required tests are successful.

Note: You must have the Okta Browser Plugin installed with Allow in Incognito enabled before you use the OIN Submission Tester. See OIN Wizard requirements.

Navigate directly to test your integration

You can navigate directly to the OIN Wizard Test integration page if you have an existing submission in the Your OIN Integrations dashboard. You can bypass the Select protocol, Configure your integration, and Test your integration pages in the OIN Wizard, and start generating instances for testing. This saves you time and avoids unnecessary updates to an existing integration submission.

Follow these steps to bypass the configuration pages in the OIN Wizard:

From the Your OIN Integrations dashboard, select the more icon () next to the integration submission that you want to test.
Select Test your integration from the menu.

The OIN Wizard Test integration page appears for you to generate an instance and test your integration.

Note: If you haven't specified test information in the Test your integration page, then you're directed to this page to enter testing details. You can go to the Test integration page only if the protocols, configuration, and test details are provided in your submission.

Generate instances for testing

Generate instances for testing in your Integrator Free Plan org directly from the OIN Wizard. The OIN Wizard takes the configuration and test information from your OIN submission and allows you to configure a specific integration instance to your test app. You can test the admin and end user sign-in experiences with the generated instance flow.

Note: Okta recommends that you:

Separate environments for development, testing, and production.

Use the Integrator Free Plan org as part of your development and testing environment.

Don't connect the generated app instance from the Integrator Free Plan org to your production environment. Connecting your development and testing environment with your production environment creates several potential risks, including unintentionally modifying data and misconfiguring your service. This could result in providing inadequate security or disrupting your service.

Okta recommends that you generate an instance for testing each protocol supported by your integration:

You must generate separate instances for testing if you support two SSO protocols (one for OIDC and one for SAML). The OIN Submission Tester can only test one protocol at a time.
If your SSO integration also supports SCIM, then create one instance for SCIM protocol testing and one instance for each SSO protocol testing.

There are certain conditions where you can test two protocols on one instance. You can create one instance for SSO and SCIM testing if your integration meets all of these conditions:

It supports SCIM and one SSO protocol
It doesn't support SSO JIT
The Create User SCIM operation is enabled

The Integrator Free Plan org has no limit on active instances. You can create as many test instances as needed for your integration. To deactivate any instances you no longer need, see Deactivate an app instance in your org.

Generate an instance for

SAML

Note: The steps in this section are for generating one instance to test the

SAML
protocol.
If you want to change the generate instance instructions, select the protocol you want from the Instructions for dropdown list on the right.

From the Test integration page, click Generate instance.

A page appears to add your instance details. See Add existing app integrations (opens new window).

When your integration is published in the OIN catalog, the customer admin uses the Admin Console Browse App Catalog > add an existing app integration (opens new window) page to add your integration to their Okta org. The next few steps are exactly what your customer admins experience when they instantiate your integration with Okta. This enables you to assume the customer admin persona to verify that app labels and properties are appropriate for your integration.

If you need to change any labels or properties, go back to edit your submission.

Note: The Integrator Free Plan has no limit on active app instances. You can create as many test instances as needed for your integration. To deactivate any instances that you no longer need, see Deactivate an app instance in your org.

Specify the Application label and any integration properties required in the General settings tab.
Click Done. The Assignments tab appears. You can assign users to your integration later, see Assign test users to your integration.
Click the Sign On tab.
Click View SAML setup instructions to open a new tab to your integration setup instructions. This is the customer configuration guide that you previously specified in the OIN Wizard.
Follow the instructions in your guide to set up the SAML SSO integration on your app.
- Click Copy next to Metadata URL to copy the full SAML metadata URL required for the integration.
- To view specific SAML metadata details, click the More details arrow.
Follow these steps if you have an Identity Engine Okta Integrator Free Plan org:
1. Click the Sign On tab, scroll to the User authentication section, and click Edit.
2. Select Password only from the Authentication policy dropdown menu.
3. Click Save.
Note: Okta Integrator Free Plan orgs are Identity Engine orgs. See OIN Wizard authentication policy for testing.
Assign test users to your instance before you start testing your SSO flows.

Assign test users to your integration instance

For SSO-only flow tests, create your test users in Okta before you assign them to your integration. See Add users manually (opens new window) and Assign app integrations (opens new window) topics in the Okta product documentation.

For SSO flow tests without JIT provisioning, you need to create the same test user in your app. If your integration supports JIT provisioning, Okta provisions the test user on your app automatically.

For SCIM provisioning, you can assign an imported user to your app. Alternatively, you can create a user in Okta that can be pushed to your app through SCIM before you assign the user to your app. See About adding provisioned users (opens new window).

Note: You need to have the org admin role assigned to you before you can create users in Okta.

To assign test users to your integration:

Continue from the OIN Wizard > Test integration > Generate instance > your app instance page.
Click the Assignments tab.
Click Assign, and then select either Assign to People or Assign to Groups.
Enter the appropriate people or groups that you want to have SSO into your app, and then click Assign for each.
Verify the user-specific attributes for any people that you add, and then select Save and Go Back.
Click Done.
Click Begin testing (upper-right corner) from the OIN Wizard. After the Test integration page appears, continue to the Application instances for testing section to include your test instance in the OIN Submission Tester.

Note: If you're not in the OIN Wizard, go to Your OIN Integration > Select protocol > Configure your integration > Test integration.

Required app instances

The Required app instances box shows you the instances detected in your org that are available to test your integration. It also shows you the test instances required for the OIN Submission Tester based on your selected protocols:

The CURRENT VERSION status indicates the instances that you need to test your current integration submission.
The PUBLISHED VERSION status indicates the instances that you need to test backwards compatibility if you edit a previously published integration. See Update a published integration with the OIN Wizard.

Application instances for testing

The Application instances for testing section displays, by default, the instances available in your org that are eligible for submission testing.

Note: The filter () is automatically set to only show eligible instances.

An instance is eligible if it was generated from the latest version of the integration submission in the OIN Wizard. An instance is ineligible if it was generated from a previous version of the integration submission and you later made edits to the submission. This is to ensure that you test your integration based on the latest submission details.

If you modify a published OIN integration, you must generate an instance based on the currently published integration for backwards-compatibility testing. A backwards-compatible instance is eligible if it was generated from the published version of the integration before any edits are made in the current submission. The OIN Wizard detects if you're modifying a published OIN integration and asks you to generate a backwards-compatible instance before you make any edits.

Note: The Integrator Free Plan org has no limit on active instances. You can create as many test instances as needed for your integration. To deactivate any instances you no longer need, see Deactivate an app instance in your org.

Add to Tester

Note: The OIN Submission Tester only supports SSO integrations. The Add to Tester option isn't available for SCIM integrations.

Click Add to Tester next to the instance in the Application instances for testing list to include it for testing with the OIN Submission Tester. The Add to Tester option only appears for SSO instances that are active and eligible for testing.

The corresponding test cases are populated with the instance name and the Run test option is enabled in the OIN Submission Tester.
Click Remove from Tester to disable the test cases that are associated with the SSO instance.

The instance name and test results are removed for the corresponding test cases in the OIN Submission Tester. The Run test option is also disabled.

Deactivate an app instance in your org

To deactivate an instance from the OIN Wizard:

Go to Test integration > Application instances for testing.
Click Clear filters to see all instances in your org.
Disable the ACTIVE toggle next to the app instance you want to deactivate.

Alternatively, to deactivate an app instance without the OIN Wizard, see Deactivate app integrations (opens new window).

Update an app instance in your org

To edit the app instance from the OIN Wizard, follow these steps:

Go to Test integration > Application instances for testing.
Click Clear filters to see all instances in your org if you don't see the instance that you want to edit.
Select Update instance details from the more icon () next to the app instance you want to update. The instance details page appears.
Edit the app instance. You can edit app instance settings or assign users to your app instance (opens new window).
Return to the OIN Wizard:
- Click Begin testing (upper-right corner) for the current submission instance.
  
  The Test integration page appears.
- Click Go to integrations (upper-right corner) for the backwards-compatible instance.
  
  The Your OIN Integrations dashboard appears. Go to your integration submission > Configure your integration > Get started with testing to continue with testing your integration.

Note: After you edit a test instance, any previous test results for that instance are invalid and removed from the OIN Submission Tester. Rerun all the required tests again with the new instance.

OIN Submission Tester

Note: The OIN Submission Tester only supports SSO integrations.

The Test integration page includes the integrated OIN Submission Tester, which is a plugin app that runs the minimal tests required to ensure that your sign-in flow works as expected. Ideally, you want to execute other variations of these test cases without the OIN Submission Tester, such as negative and edge test cases. You can't submit your integration in the OIN Wizard until all required tests in the OIN Submission Tester pass.

Before you start testing with the OIN Submission Tester, see OIN Wizard test requirements.

Notes:

Click Initialize Tester if you're using the OIN Submission Tester for the first time.

Click Refresh Tester session for a new test session if the OIN Submission Tester session expired.

See Troubleshoot the OIN Submission Tester if you have issues loading the OIN Submission Tester.

The OIN Submission Tester includes the mechanism to test the following flows:

IdP flow
SP flow
Just-In-Time (JIT) provisioning (with IdP flow)
Just-In-Time (JIT) provisioning (with SP flow)

Note: The JIT provisioning (with SP flow) test case appears in the OIN Submission Tester if your integration supports JIT and only the SP flow. If your integration supports JIT, IdP, and SP flows, then a successful JIT provisioning (with IdP flow) test is sufficient for submission.

The test cases for these flows appear in the Test integration using the OIN Submission Tester section depending on your OIN Wizard test information.

Note: See Run test for the steps on how to run each test case.

Your test results in the OIN Submission Tester are valid for 48 hours after the test run. Rerun all your test cases in the OIN Submission Tester if they expired.

Submit your integration if all your tests have passed. If you have errors, see Failed tests to resolve the errors.

Run tests

The Run test option is enabled for test cases with an eligible test instance.

After you click Run test, the OIN Submission Tester opens a browser window in incognito mode. Use the incognito browser window to execute the test and verify it with the Test in progress dialog that appears in the upper-right corner.

Run the IdP flow test

To run the IdP flow test:

Click Run test next to the IdP flow test case.

A new Chrome browser in incognito mode appears for you to sign in.
Sign in to Okta as an end user that was assigned to your test app instance.
- Your app tile appears on the Okta End-User Dashboard.
- The Tester selects your app tile and you're signed in to your app.
Verify that the test end user signed in to your app with the correct profile.
Select The user successfully signed in to your app in the upper-right Test in progress dialog to confirm that the IdP flow test passed.
Click Continue from the Test in progress dialog to sign out of your app.

The incognito browser closes and you're redirected back to the OIN Submission Tester. The OIN Submission Tester records the test run result and timestamp.
Click the IdP flow expand icon () to view the test steps and network traffic details for the test run.

If your test run wasn't successful, this is a useful tool to troubleshoot the issues and correct your integration, instance, or submission details.

Run the SP flow test

To run the SP flow test:

Click Run test next to the SP flow test case.

A new Chrome browser in incognito mode appears for you to sign in.
Sign in to your app as the test end user that was assigned to your app instance.
Verify that the test end user signed in to your app with the correct profile.
Select The user successfully signed in to your app in the upper-right Test in progress dialog to confirm that the SP flow test passed.
Click Continue from the Test in progress dialog to sign out of your app.

The incognito browser closes and you're redirected back to the OIN Submission Tester. The OIN Submission Tester records the test run result and timestamp.
Click the SP flow expand icon () to view the test steps and network traffic details for the test run.

Run the JIT provisioning with IdP flow test

For the JIT provisioning test, the OIN Submission Tester creates a temporary Okta test user account for you to verify that JIT provisioning was successful. The Tester then removes the test user account from Okta to complete the test.

Notes:

Ensure that your app integration supports JIT provisioning before you run the JIT provisioning test.

For JIT provisioning testing, you must have either the super admin role or both the app admin and org admin roles assigned to you.

The JIT provisioning test case appears only if you select Supports Just-In-Time provisioning in your submission.

To run the JIT provisioning with IdP flow test:

Click Run test next to the JIT provisioning (w/ IdP flow) test case.

The OIN Submission Tester executes the following steps for the JIT provisioning test case:
1. Creates a user in Okta and assigns them to the test app instance.
2. Open an incognito browser window to sign in to Okta.
3. Sign in to Okta as the new test user.
4. Select the app tile.
5. Wait for confirmation that the new test user signed in and was provisioned in your app (you're responsible to verify this step).
Verify that the test user signed in to your app with the correct first name, last name, and email attributes.

Note: You can go back to the OIN Submission Tester window and expand the test case to view network traffic details for this test run. The NETWORK TRAFFIC tab contains API calls to Okta with the test user details in the request payload.
Select The user successfully signed in to your app in the upper-right Test in progress dialog to confirm that the JIT provisioning IdP flow test passed.
Click Continue from the Test in progress dialog to sign out of your app.

The OIN Submission Tester executes the following steps after you click Continue:
1. Signs out of the app and closes the incognito browser window.
2. Unassigns the test user from the app instance in Okta.
3. Deletes the test user from Okta.
4. Records the test run result and timestamp in the OIN Submission Tester.
5. Redirects you back to the OIN Submission Tester.
Click the JIT provisioning (w/ IdP flow) expand icon () to view the test steps and network traffic details for the test run.

Note: The test user account created in your app from JIT provisioning persists after the JIT provisioning test. The OIN Submission Tester only removes the temporary test user account from your Okta org. It's your responsibility to manage the JIT test user accounts in your app.

Run the JIT provisioning with SP flow test

You're only required to pass one JIT provisioning test case to submit your integration. The OIN Submission Tester includes the JIT provisioning (w/ SP flow) test case if you support JIT and only the SP flow. If your integration supports JIT, IdP, and SP flows, then a successful JIT provisioning (w/ IdP flow) test is sufficient for submission.

Similar to the JIT provisioning with IdP flow test, the OIN Submission Tester creates a temporary Okta test user account for you to verify that JIT provisioning was successful. The Tester then removes the test user account from Okta to complete the test.

Follow the same steps in Run the JIT provisioning with IdP flow test to run the JIT provisioning with SP flow test. The only difference in the SP test is that the OIN Submission Tester opens an incognito browser window to sign in to your app first.

Failed tests

If any of your test cases fail, investigate and resolve the failure before you submit your integration. You can only submit integrations that have successfully passed all the required tests in the OIN Submission Tester.

If you have to update SSO or test detail properties in your submission to resolve your failed test cases, then generate a new app integration instance for testing. Assign test users to your new integration instance before you execute all your SSO test cases again.

Note: You don't have to generate a new app instance for every failed test scenario. If you have an environment issue or if you forgot to assign a user, you can fix your configuration and run the tests again. Generate a new instance if you need to modify an SSO property, such as an integration variable, a redirect URI, or an ACS URL.

It's good practice to deactivate your test instances that aren't in use. You can later delete the instance to clean your app integration list.

If you have questions or need more support, email Okta developer support at developers@okta.com and include your test results. To obtain your test results:

From the OIN Submission Tester, click Export results (upper-right corner) to download a JSON-formatted file of all your test results.

All required tests in the OIN Submission Tester must have passed within 48 hours of submitting your integration.

Test your SCIM integration

You need to run three sets of tests for SCIM integrations:

SCIM API specification tests

You need to first test your SCIM API service before you conduct Okta-SCIM integration tests. Okta provides you with a SCIM API specification test suite to execute in Runscope. See Test your SCIM API for instructions on how to run this test suite. Provide the test results URL in the Link to Runscope spec test results field when you submit your integration to the OIN.
Runscope create, read, update, and delete (CRUD) user profile tests

Enter the results URL from these tests in the Link to Runscope CRUD test results field when you submit your integration to the OIN.
Manual Okta SCIM integration tests

You must certify that you've completed these tests when you submit your integration to the OIN.

Runscope CRUD tests

Download the Okta SCIM 2.0 CRUD Test file.

This CRUD test file is built for the BlazeMeter Runscope (opens new window) API monitoring tool. If you don't have a Runscope account, you can sign up with a free trial to Runscope (opens new window) for Okta developers.
From Runscope, click Import Test.
Select API Monitoring Tests as the import format.
Click Choose File and select the Okta SCIM 2.0 CRUD Test file.
Click Import API Test. In this new test bucket, click Editor from the left-navigation menu.
Click Test Settings and then click Initial Variables.
Add the following variables with values that match your SCIM integration:
- oktaOrgUrl: The base URL for your Okta org. Include the https:// prefix.
- oktaAppId: The unique identifier that's assigned to your test app instance. You can see this value in the App Embed Link panel under the General tab for your instance.
- oktaToken: The Okta API token used by Runscope to connect to Okta APIs. You can generate an API token inside your org. See Create an API token.
- SCIMUrl: The base URL of the SCIM service. For example: https://example.com/scim/v2
- SCIMAuth: The authorization token used to access your SCIM API. You can use the same authorization token you used to Enable API integration from Generate an instance for
  
  SAML
  .
  
  The following is an example of the Runscope variable values:
Click Test Settings and then click Initial Script.
Copy the contents of the Okta CRUD Initial Script text file and paste into this Runscope console.
Click Save & Run.

Review Runscope test results

On the left of your Runscope page, the test appears in the Recent Test Runs section.

Click View Progress from the Recent Test Runs section. As the test suite runs, Runscope displays live updates of the test in progress. After the test suite completes, the main panel displays the results of your test.
Click a test case to see its Request, Response, and Connection information.

When you're satisfied with your Runscope CRUD test results, enter them in the Link to Runscope CRUD test results field:

From your Runscope dashboard, open the test results that you want to share.
At the top of the test result, set the Private | Shareable toggle to Shareable.
Copy the URL for the test result. The test results can be viewed in detail, but the test can't be edited or rerun by people outside of your team.

Example of a test result URL: https://www.runscope.com/radar/abcdefghijkl/m01nopq2-3456-7r8s-9012-t34567uvw890/history/123ef4gh-i567-89j0-1k2l-3m4n5o678901.
Paste the test results URL into the Link to Runscope CRUD test results field in the OIN Wizard Test integration > SCIM integration testing step section.

Manual Okta SCIM integration tests

Execute the test cases in the Okta SCIM Test Plan. Skip the test cases for the features that your integration doesn't support. All the other supported-feature test cases must pass before you can submit your integration to the OIN.

Depending on your test scenario, you can import users from the Import tab (see Import users (opens new window)) or create users in Okta before assigning them to your test instance. See About adding provisioned users (opens new window) and Assign test users to your integration instance.

After you've successfully completed the manual SCIM integration tests, you can submit your integration.

Submit your integration

After you successfully test your integration, you're ready to submit.

The OIN Wizard checks the following for SSO submissions:

All required instances are detected.
All required instances are active.
All required tests passed within the last 48 hours.

The OIN Wizard checks the following for SCIM submissions:

All required instances are detected.
All required instances are active.
The Link to Runscope spec test results field is specified.
The Link to Runscope CRUD test results field is specified.

Note: See Test your SCIM integration for SCIM submission requirements.

Submit integration is enabled after all these requirements are met.

Select I certify that I have successfully completed required tests.
Click Submit integration to submit your integration.
Click Close wizard. The Your OIN Integration dashboard appears.

After you submit your integration, your integration is queued for OIN initial review. Okta sends you an email with the expected initial review completion date.

The OIN review process consists of two phases:

The initial review phase
The QA testing phase

Okta sends you an email at each phase of the process to inform you of the status, the expected phase completion date, and any issues for you to fix. If there are issues with your integration, make the necessary corrections and resubmit in the OIN Wizard.

Note: Sometimes, your fix doesn't include OIN Wizard edits to your integration submission. In this case, inform the OIN team of your fix so that they can continue QA testing.

Check the status of your submission on the Your OIN Integrations dashboard.

See Understand the submission review process.

Submission support

If you need help during your submission, Okta provides the following support stream for the various phases of your OIN submission:

Building an integration phase
- When you're constructing your SSO app integration, you can post a question on the Okta Developer Forum (opens new window) or submit your question to developers@okta.com.
Using the OIN Wizard to submit an integration phase
- If you need help with the OIN Wizard, review this document or see Publish an OIN integration.
- Submit your OIN Wizard question to developers@okta.com if you can't find an answer in the documentation.
- If you have an integration status issue, contact oin@okta.com.
Testing an integration phase
- If you have issues during your integration testing phase, you can post a question on the Okta Developer Forum (opens new window) or submit your question to developers@okta.com.

On this page

Submit an integration with the OIN Wizard

What you need

Overview

Protocols supported

Start a submission

Configure your integration

OIN catalog properties

Integration variables

SAML
properties

Dynamic properties with Okta Expression Language

Enter test information

Test information for Okta review

SAML
tests

Test your integration

Navigate directly to test your integration

Generate instances for testing

Generate an instance for

SAML

Assign test users to your integration instance

Required app instances

Application instances for testing

Add to Tester

Deactivate an app instance in your org

Update an app instance in your org

OIN Submission Tester

Run tests

Run the IdP flow test

Run the SP flow test

Run the JIT provisioning with IdP flow test

Run the JIT provisioning with SP flow test

Failed tests

Test your SCIM integration

Runscope CRUD tests

Review Runscope test results

Manual Okta SCIM integration tests

Submit your integration

Submission support

See also

On this page

Submit an integration with the OIN Wizard

What you need

Overview

Protocols supported

Start a submission

Configure your integration

OIN catalog properties

Integration variables

SAML properties

Dynamic properties with Okta Expression Language

Enter test information

Test information for Okta review

SAML tests

Test your integration

Navigate directly to test your integration

Generate instances for testing

Generate an instance for SAML

Assign test users to your integration instance

Required app instances

Application instances for testing

Add to Tester

Deactivate an app instance in your org

Update an app instance in your org

OIN Submission Tester

Run tests

Run the IdP flow test

Run the SP flow test

Run the JIT provisioning with IdP flow test

Run the JIT provisioning with SP flow test

Failed tests

Test your SCIM integration

Runscope CRUD tests

Review Runscope test results

Manual Okta SCIM integration tests

Submit your integration

Submission support

See also

SAML
properties

SAML
tests

Generate an instance for

SAML