---
title: "Setting Up Okta for SSO in Express View (SAML)"
slug: "setting-up-okta-for-sso-in-express-view-saml"
updated: 2026-04-06T17:11:49Z
published: 2026-05-15T13:32:28Z
canonical: "docs.unqork.io/setting-up-okta-for-sso-in-express-view-saml"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.unqork.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Setting Up Okta for SSO in Express View (SAML)

## Overview

In this article, you'll learn how to use Okta as an SSO (single sign-on) provider, using the SAML (Security Assertion Markup Language) authentication method. Okta acts as the IdP (Identity Provider) and Unqork is the SP (Service Provider). You'll set up your SAML configuration using Single Sign-On (SSO) Management.

> [!NOTE]
> To connect Okta to your Unqork application as an SSO provider, your Okta administrator needs to set up a new Okta app integration. To learn more, see Okta's **Create a SAML integration using AIW** article here: [https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard_SAML.htm](https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard_SAML.htm).

## How Settings Map Between Okta and Unqork

In the following table and images, you can see how key SAML configuration settings in Okta map to the SAML configuration fields in Unqork.

| # | Unqork Setting | Related Okta Setting |
| --- | --- | --- |
| 1 | Copy Metadata URL > [!NOTE] > This setting location is where you copy the URL of the SP metadata XML file. | > [!NOTE] > Okta doesn't need or support uploading an SP metadata XML file to create a SAML app integration. There's no direct setting mapping between Unqork and Okta. However, the Okta administrator might request an SP metadata XML file to help verify settings. |
| 2 | IdP Metadata XML > [!NOTE] > This setting location is where you insert the IdP metadata XML data. | Identity Provider Metadata > [!NOTE] > This Okta setting location is where you download the IdP metadata XML file. |
| 3 | SAML SP Entity ID | Audience URI (SP Entity ID), Audience Restriction > [!NOTE] > The Audience URI (SP Entity ID) is set when creating the app integration. After creating the app integration, the Audience URI (SP Entity ID) displays as the Audience Restriction. |
| 4 | SAML Callback URL | Single Sign-On URL > [!TIP] > Be sure the URL shows the Express View-specific host value. For example unqork-uat**x**.unqork.io, not unqork-uat.unqork.io. |

![](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/sso_okta_unqorkSettingMapping(1).jpg?sv=2026-02-06&spr=https&st=2026-11-09T03%3A51%3A20Z&se=2026-11-09T04%3A51%3A20Z&sr=c&sp=r&sig=wmiUHh1Y4cpQ9Nxa9zkJh6i1c5yCCOYqGjhq6r7QfXg%3D)

![](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/sso_okta_oktasidesettingmappingsaml.jpg?sv=2026-02-06&spr=https&st=2026-11-09T03%3A51%3A20Z&se=2026-11-09T04%3A51%3A20Z&sr=c&sp=r&sig=wmiUHh1Y4cpQ9Nxa9zkJh6i1c5yCCOYqGjhq6r7QfXg%3D)

## Setting Up Okta as a SAML Configuration in Single Sign-On (SSO) Management

This is a step-by-step walkthrough of how to set up Okta as a SAML configuration. It is one example of how you might configure Okta for SSO in Express View. This approach ensures Okta is the single source of truth for your end-user's permissions.

> [!TIP]
> To learn more about all the SAML configuration settings in Single Sign-On (SSO) Management, search **Unqork as a SAML Service Provider** in our In-Product Help. To learn more about using the Single Sign-On (SSO) Management dashboard, search **Single Sign-On (SSO) Management** in our In-Product Help.

### What You Need

For this sample configuration, you need the following information:

- The IdP metadata XML file (SAML metadata) from Okta.

> [!TIP]
> In some cases, the Okta administrator requests the SP metadata XML file before they provide the IdP metadata XML file. To learn how to generate a placeholder SP metadata XML file, see [Provide Okta With a Placeholder SP metadata XML File](/v1/docs/setting-up-okta-for-sso-in-express-view-saml#providing-okta-with-a-placeholder-sp-metadata-xml-file).
- A list of SAML attributes to map to Unqork attributes.

> [!NOTE]
> Your specific values vary based on your use case. Work with the Okta administrator to ensure both sides are clear on what information your application needs to access.

### Start the Configuration

1. At the top right of the Unqork Designer Platform, click the **Settings** drop-down.
2. Click **Administration**.
3. Under Environment, select **Single Sign-On (SSO)**.
4. Click **+ New SSO**.
5. From the + New SSO drop-down, select **Express**.

### Basic Information Tab

The Basic Information tab is the first tab you see when the New Express SSO configuration modal opens. In this tab, you name your configuration and assign end-user permissions.

1. In the **SSO Name** field, enter a unique name for your configuration.

> [!TIP]
> This name is used to generate the default SP Entity ID.
2. In the **Default Role** drop-down, select a role.

> [!NOTE]
> When setting up SSO for Express View, select a default role with the lowest-level permissions. This lets you rely on the value stored in Okta to determine higher-level permissions.
3. In the **Default Groups** list, select one or more groups.

> [!NOTE]
> Adding Default Groups is optional. By default, no groups are selected.
4. Click **Next**.

You progress from the Basic Information tab to the Configure Protocol tab.

### Configure Protocol Tab

Now, select the SAML protocol from the Configure Protocol tab. Then, add the IdP metadata XML file you received from Okta. Once added, the XML file is automatically parsed to autofill related configuration fields.

1. Select **SAML** as the **Protocol**.
2. In a text editor, open the IdP metadata XML file provided by Okta.
3. In the **IdP Metadata XML** field, copy and paste the contents of the file.

The **SAML IdP NameID Format**, **SAML IdP SSO URL**, and **SAML IdP X.509 Certificate** fields autofill. If the metadata is incorrect, an error message displays asking you to check the XML.

> [!NOTE]
> The SAML IdP NameID Format field is optional. The default value for this field is urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. The NameID is a unique identifier that matches an end-user across multiple Unqork sessions.

> Alternatively, you can connect to a public IdP URL to refresh the IdP Metadata and Certificate data every hour. For more details, view the [Advanced Section](/v1/docs/unqork-as-a-saml-service-provider#advanced-settings) in our [Unqork as a SAML Service Provider](/v1/docs/unqork-as-a-saml-service-provider) article.
4. In the **SAML SP Entity ID** field, enter a value.

> [!NOTE]
> This value must match the value used by the IdP. If you're asked to define the Entity ID, use a value that relates to your configuration. For example, {environment name and codebase}-{application name}-saml. The Okta administrator might also have their own preferred Entity ID naming conventions.
5. You can leave the default value for the **SAML Callback URL** field unless the Okta app integration uses a different value.
6. Click **Next**.

You progress from the Configure Protocol tab to the Attribute Mapping tab.

> [!NOTE]
> The Configure Protocol tab has several advanced settings you can enable. To access these settings, click **Show Advanced Settings**. Whether or not you need to enable these settings depends on your use case. For this Okta configuration, enabling any Advanced Settings is not required. Visit the [Unqork as a SAML Service Provider](/v1/docs/unqork-as-a-saml-service-provider) article for more information.

### Attribute Mapping Tab

Next, map attributes in the SAML assertion sent by the IdP to Unqork attributes in the session's currentUser object. For example, mapping the IdP-provided email address to the Unqork attribute email.

> [!CAUTION]
> By default, the Attribute Mapping tab includes the mapping {{NameID}} to userId. Do not delete this mapping or your SSO configuration can fail.

> [!TIP]
> You can create dynamic, conditional, or static attribute mappings. See the **Creating Attribute Mappings** section in our **Unqork as a SAML Service Provider** article for more information and detailed examples.

To add an attribute mapping:

1. Click **+ Add Attribute Mapping**.
2. Complete the **SAML Claim** side of the mapping.
3. From the **Unqork Attribute** drop-down, select a default Unqork attribute. Or, enter the attribute's name in the **Unqork Attribute** field then press **Enter/Return** or select **Create "{attribute name}"**.

> [!NOTE]
> Unqork attributes include email, userId, name, and phone.
4. Repeat the above steps as needed.

> [!NOTE]
> To learn more about attribute mapping, see the **Attribute Mappings** section in our **Unqork as a SAML Service Provider** article.

#### User Management

These user management settings are more variable and highly dependent on your unique use case. However, in this configuration Okta is the single source of truth for authentication. This means the user doesn't need to exist in Unqork, as Unqork isn't acting as the user management system. So, consider the following settings:

1. Click **Show User Management**.
2. Verify **Disable New User Creation** is selected.

> [!CAUTION]
> Don’t enable **Disable New User Creation** if you plan to modify users via an API call in the platform. Enabling this setting prevents user modification using an API call.
3. Click **Create SSO**.

> [!NOTE]
> Verify the SSO configuration in Environment Administration matches the SSO configuration in Single Sign-On (SSO) Management. If you are encountering issues, visit the [Troubleshooting Tips](/v1/docs/setting-up-okta-for-sso-in-express-view-saml#troubleshooting-tips) section below.

Your SSO configuration is now complete. The configuration modal closes and returns your focus to the Single Sign-On (SSO) Management dashboard.

## Providing Okta With a Placeholder or Final SP Metadata XML File

There are two scenarios where you might need to provide the Okta administrator with an SP metadata XML file:

- **Providing a placeholder XML file**: The Okta administrator requests the SP metadata XML file before they provide the IdP metadata XML file. Receiving the SP metadata XML file first lets the administrator configure the Okta side of the SSO integration around Unqork's default settings or an Unqork-defined SAML SP Entity ID.
- **Providing a final XML file**: The Okta administrator requests the XML file after you complete your SSO configuration based on the IdP metadata XML file.

It's possible neither scenario occurs when you create your SSO configuration. However, this section covers how to proceed in both scenarios.

### Providing Okta With a Placeholder SP Metadata XML File

If the Okta administrator requests the SP metadata XML file before they provide the IdP metadata XML file, you can configure a placeholder SP metadata XML file.

To add a SAML configuration to your environment:

1. At the top right of the Unqork Designer Platform, click the **Settings** drop-down
2. Click **Administration**.
3. Under Environment, select **Single Sign-On (SSO)**.
4. Click **+ New SSO**.
5. From the + New SSO drop-down, select **Express**.
6. In the **SSO Name** field, enter a unique name for your configuration.

> [!TIP]
> This name is used to generate the default SP Entity ID. Use a descriptive name that relates to your configuration. For example, {environment name and codebase}-{application name}-saml.
7. Select a Default Role and Default Group(s) as needed.
8. Click **Next**.
9. From Select Protocol, select **SAML**.
10. Click **Copy Metadata Url**.

> [!NOTE]
> The SP metadata XML file generates based on the current state of your SAML configuration. When generating the SP metadata XML file before parsing an IdP metadata XML file, the SP metadata XML file uses default configuration values.
11. Open a new tab in your browser.
12. Paste the URL in the address bar and press Enter/Return.
13. Copy the XML from your browser tab into a text editor like Sublime Text.
14. Save the XML as a .xml file.

Now you can send the SP Metadata XML file to the Okta administrator.

### Providing Okta With the Final SP Metadata XML File

> [!NOTE]
> If you already provided the Okta administrator with a placeholder SP metadata XML file, you can skip this step. However, if you made any changes to your SAML configuration after receiving the IdP metadata XML file, you might need to resend the SP metadata XML file.

If you started your SAML configuration by parsing an IdP metadata XML file, you might need to provide the IdP with the SP metadata XML file.

To download the SP metadata XML file:

1. From the **Single Sign-On (SSO) Management** dashboard, open your SSO configuration and navigate to the **Configure Protocol** tab.
2. Click **Copy Metadata Url**.
3. Open a new tab in your browser.
4. Paste the URL in the address bar and press **Enter/Return**.
5. Copy the XML from your browser tab into a text editor like Sublime Text.
6. Save the XML as a .xml file.

Now you can send the SP metadata XML file to the Okta administrator.

## Testing Your Configuration

After completing the Unqork side of the setup, test your configuration.

> [!NOTE]
> You'll need a set of test credentials from the Okta administrator. The test user must be assigned to the app integration in Okta, under the Assignments tab.

### Testing an SP-Initiated Flow

From the SSO dashboard, you can preview the Unqork entrypoint and use a set of test credentials from your SSO provider to test the configuration. To test the SP-initiated flow:

1. At the top right of the Unqork Designer Platform, click the **Settings** drop-down.
2. Click **Administration**.
3. Under Environment, select **Single Sign-On (SSO)**.
4. In the SSO dashboard, find the SSO configuration to preview.
5. Under the Actions column, click **Manage**.
6. From the Manage drop-down, right-click **Preview**.
7. Click **Open Link in Incognito Window**.

> [!TIP]
> By default, the Unqork entrypoint URL uses 123 as the module ID. To test access to an actual module in your application, replace 123 at the end of the URL with your module's module ID.
8. Log in using your test credentials.

If you see an error page, there are issues with your configuration. If you can successfully log in to Unqork, your SAML configuration of Okta as SSO provider is working.

### Testing an IdP-Initiated Flow

To test the IdP-initiated login flow, you'll need the Embed Link found in Okta.

1. In Okta, navigate to the **Applications** page.
2. Select your app integration.
3. In the **Embed Link** field, copy the value.

![](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/sso_okta_appEmbedLink_thumb_0_0(1).jpg?sv=2026-02-06&spr=https&st=2026-11-09T03%3A51%3A20Z&se=2026-11-09T04%3A51%3A20Z&sr=c&sp=r&sig=wmiUHh1Y4cpQ9Nxa9zkJh6i1c5yCCOYqGjhq6r7QfXg%3D)
4. Open a new Incognito window of your browser.
5. Paste the **Embed Link** into the browser.
6. Log in using your test credentials.

If you see an error page, there are issues with your configuration. If you can successfully log in to Unqork, your SAML configuration of Okta as SSO provider is complete.

### Troubleshooting Tips

Understanding what's causing an error is one of the most frustrating parts of creating a new configuration. One of the most common sources of error is not using the Express View-specific host value in the **SAML Callback URL** field. By default, new Express SSO configurations use the Express View-specific host value in the SAML Callback URL. However, double-checking the location attribute in the SP metadata XML file can confirm this. Also ensure the SAML Callback URL value exactly matches the **Single Sign-On URL** in Okta, and both values use the Express View-specific host value.

To figure out what exactly is wrong, it's useful to view what assertions your application receives from Okta. Assertions aren't logged in Service Logs. Instead, you can use Google Chrome extensions such as [SAML Chrome Panel](https://chrome.google.com/webstore/detail/saml-chrome-panel/paijfdbeoenhembfhkhllainmocckace) or [SAML Message Decoder](https://chrome.google.com/webstore/detail/saml-message-decoder/mpabchoaimgbdbbjjieoaeiibojelbhm) for this. Comparing the assertions you receive against the assertions you expect can help with debugging.