# Okta Integration
## Overview
This section provides instructions on:
* [Okta authentication](#okta-authentication): How to configure WorkflowGen authentication using Okta.
* [Okta user provisioning](#okta-user-provisioning): How to create a directory with the self-provisioning connector.
* [Okta configuration for WorkflowGen Plus v2](#okta-configuration-for-workflowgen-plus-v2): How to authorize WorkflowGen access to mobile applications using Okta.
* [Okta configuration for server-side scripts](#okta-configuration-for-server-side-scripts): How to authorize WorkflowGen access to server-side scripts using Okta.
* [Okta configuration for single-page applications](#okta-configuration-for-single-page-applications): How to authorize WorkflowGen access to single-page applications using Okta.
* [Okta configuration for the WorkflowGen CLI](#okta-configuration-for-the-workflowgen-cli): How to authorize Okta access to the WorkflowGen command line interface.
* [Generating a universal link for WorkflowGen Plus v2](#generating-a-universal-link-for-workflowgen-plus-v2): How to generate a universal link to simplify the WorkflowGen Plus mobile app user login.
It also provides additional information on [WorkflowGen SOAP API services support](#workflowgen-soap-api-services-support) and [Web service type application support](#web-service-type-application-support).
{% hint style="warning" %}
In the instructions, substitute `` with the domain and path to your WorkflowGen instance; for example, `localhost/wfgen` or `mycompany.com/wfgen`.
{% endhint %}
## Okta authentication
This section provides instructions on how to configure WorkflowGen delegated authentication with Okta. At the end of this section, you'll have a working WorkflowGen instance using Okta to authenticate your users.
{% hint style="info" %}
If you don't need the GraphQL API, you won't need to create an authorization server. See the [Configuring the authentication without the GraphQL API ](#configuring-the-authentication-without-the-graphql-api)section for instructions.
{% endhint %}
### Prerequisites
* Make sure to have a licensed copy of WorkflowGen installed and running on a server. You must be a WorkflowGen administrator.
* Make sure to have an Okta administrator access to be able to configure it properly.
* Make sure to have provisioned an existing Okta user that you can authenticate with to WorkflowGen and that the user has administrator privileges. This is important because once you've activated the delegation, you'll still need to be able to manage the application. (The Okta user is in fact a user of an identity provider that's linked to Okta, such GitHub or Google. You have to provision at least one of the users.)
* AES encryption mode and its key are required for the authentication to work.
{% hint style="warning" %}
* The WorkflowGen user's **username** must match their Okta user's **username** in order to identify and authenticate the correct user from Okta.
* To test your configuration after the steps below, you can add an Okta user in the Okta portal's **Users** section.
* When importing users into WorkflowGen from the Okta database, make sure to set the username as the email (e.g. `john.doe@example.com`).
{% endhint %}
### Configuring the authentication with the GraphQL API
The configuration of Okta will be done in several steps. First, you have to configure an authorization server in the web interface; then, you have to add a regular web application.
{% hint style="warning" %}
The WorkflowGen GraphQL API (authorization server) configuration is **required** if you want to use the **WorkflowGen Plus v2** mobile app.
{% endhint %}
#### Step 1: Create an authorization server
An Okta authorization server is a logic element that defines the security boundaries of your system when an application wants to access your resources via an API.
> An authorization server defines your security boundary, and is used to mint access and identity tokens for use with OIDC clients and OAuth 2.0 service accounts when accessing your resources via API. Within each authorization server you can define your own OAuth scopes, claims, and access policies.\
> \
> \&#xNAN;*Source: Information sidebar in Okta's administrative panel*
You can find more information on authorization servers on the [Okta developer website](https://developer.okta.com/authentication-guide/implementing-authentication/set-up-authz-server).
**To create an authorization server with a classic usage:**
1. Go to the Okta Developer portal and log in to your account.
2. In the left panel, choose **API** under the **Security** menu.
3. Click the **Add Authorization Server** button on the **Authorization Servers** tab.
4. Enter the following information:
* **Name:** `WorkflowGen GraphQL API`
* **Audience:** `/graphql`
* **Description:** `WorkflowGen GraphQL API` (or whatever description you want)
5. Click the **Save** button.
**To create an authorization server with multi-audience support:**
1. Go to the Okta Developer portal and log in to your account.
2. In the left panel, choose **API** under the **Security** menu.
3. Click the **Add Authorization Server** button on the **Authorization Servers** tab.
\
4. Enter the following information:
* **Name:** `My APIs`
* **Audience:** `my-apis`
* **Description:** `Authorization server for all my APIs` (or whatever description you want)
5. Click the **Save** button.
#### Step 2: Add the scope
**For classic usage:**
1. Go to the WorkflowGen GraphQL API authorization server's **Scopes** tab.\
\
2. Click the **Add Scope** button.
3. Enter the following information:
* **Name:** `default`
* **Display phrase**: `default`
* **Description:** `Use the default scope if no other scope is specified`
* **Default scope:** Check `Set as a default scope`
\
4. Click the **Create** button.
**For multi-audience support:**
1. Go to the WorkflowGen GraphQL API authorization server's **Scopes** tab.\
\
2. Click the **Add Scope** button.
3. Enter the following information:
* **Name:** `wfgen-graphql-full-access`
* **Display phrase**: `wfgen-graphql-full-access`
* **Description:** `Full access to the WorkflowGen GraphQL API`
\
4. Click the **Create** button.
You've now properly configured your Okta authorization server for the WorkflowGen GraphQL API.
#### Step 3: Add a claim
1. Go to the **Claims** section, then click the **Add Claim** button.
2. Enter the following information:
* **Name:** `com.workflowgen.api.username`
* **Include in token type:** Select `Access Token`
* **Value Type:** Select `Expression`
* **Value:** Enter the following Okta code:
```javascript
appuser.username != null ? appuser.username : appuser.email != null ? appuser.email : appuser.nickname != null ? appuser.nickname : null
```
* **Include in:** Select `Any scope`
✏️ **Note:** This step will ensure that WorkflowGen and the GraphQL API will always get a username through the same claim instead of having to make a lot of conditional statements.\
\
3. Click the **Create** button.
4. Add a **second claim** with the same information, but this time, set the **Include in token type** property to `ID Token`.\
\
5. Click the **Create** button.
#### Step 4: Add the server access policy
You now need to configure the authorization server access policy.
1. Go to the WorkflowGen GraphQL API authorization server's **Access Policies** tab.
2. Click the **Add Policy** button.
3. Enter the following information:
* **Name:** `All Clients Policy`
* **Description:** `Enables all clients to have access to this application server›.`
* **Assign to**: `All clients`
\
4. Click the **Create Policy** button.
5. Click the **Add Rule** button.
6. Enter the following information:
* **Rule Name:** `All Grant Types; Any Scopes; Any User assigned`
* Leave the other settings set to their defaults.
7. Click the **Create Rule** button.
You've now successfully configured the authorization server access policy. There's just one more step needed in order for the client credentials flow to work, which will enable you to use machine-to-machine authentication with Okta and the WorkflowGen GraphQL API.
#### Step 5: Create the WorkflowGen web application
1. Go to the Okta Developer portal.
2. In the **Applications** item under the **Applications** menu, click the **Create App Integration** button.
3. Select the following options in **Create a new app integration**, then click **Next**:
* **Sign-in method:** `OIDC - OpenID Connect`
* **Application type:** `Web Application`
4. Enter the following information:
* **App integration name:** `WorkflowGen`
* **Grant type:** Check `Authorization Code`
* **Sign-in redirect URIs:** `/auth/callback`
* **Sign-out redirect URIs:** `/auth/logout/return`
* **Base URIs:** `` without any path (just the base URL); for example, `https://localhost`, if `` is `https://localhost/wfgen`
* **Controlled access:** Check `Allow everyone in your organization to access`
* Leave the remaining properties set to their defaults.\
\
\
\
5. Click the **Save** button.
6. On the **General** tab of your WorkflowGen web application page, click the **Edit** button in the **General Settings** section.
7. Enter the following information:
* **Initiate login URI**: `/auth/callback`
\
8. Click **Save**.
You've now successfully configured Okta for your WorkflowGen instance.
#### Review the registration
You should now have all the information you need to configure WorkflowGen to delegate the authentication to Okta. Here's a review:
* A `client ID` and a `client secret` which can be found on the Okta **WorkflowGen** web application's **General** tab.\
\
* An `audience` and a `metadata endpoint (Metadata URI)` which can be found on the Okta **WorkflowGen GraphQL API** authorization server page.\
\
#### WorkflowGen configuration
Now, you need to configure WorkflowGen to delegate its authentication to Okta.
#### Step 1: Add Okta values to the WorkflowGen `web.config`
Open the WorkflowGen `web.config` file and **add/update** the following properties:
**Classic usage**:
```markup
```
**With multi-audience support**:
```markup
```
* Replace `` with the client ID of the **WorkflowGen** web application from Okta.
* Replace `` with the client secret of the **WorkflowGen** web application from Okta.
* Replace `` with the **Metadata URI** property found in the **WorkflowGen GraphQL API**'s **settings** page. Then, replace the last part, `/.well-known/oauth-authorization-server`, with `/.well-known/openid-configuration` (e.g. `https://{YOUR_OKTA_DOMAIN}/oauth2/{AUTH_SERVER_ID}/.well-known/openid-configuration`).
You have probably noticed that the setting with the `ApplicationSecurityAuthUsernameClaim` key is set to the value entered in a rule earlier. Therefore, you could use any value here provided that you also modify the rule.
{% hint style="info" %}
For information about available configuration options to use with your instance, see the [Web and Application Configuration Parameters](https://docs.workflowgen.com/tech/8.0/appendix-web-and-application-configuration-parameters#auth) appendix.
{% endhint %}
WorkflowGen is now linked to Okta and back. The last thing left to do is configure a few more options in order to finish the internal wiring of WorkflowGen so that it can delegate its authentication.
#### Step 2: Add some security values for session generation
In order to generate a session token, you need to add a few more settings to the `web.config` file.
1. Open the WorkflowGen `web.config` file and **add/update** the following property:
```markup
```
2. Replace `` with a value that can't be easily guessed, such as a UUID.
The secret will be only accessible inside your instance of WorkflowGen, so when generating a session token, WorkflowGen will sign it with this secret in order to check the validity of all session tokens passed to it.
#### Step 3: Activate the authentication delegation
You now need to activate the delegation by replacing the authentication system in IIS and pointing WorkflowGen's modules to the correct authentication module.
**Configure IIS**
1. In **IIS Manager**, click on the WorkflowGen application in the tree view.
2. Click the **Authentication** button.
3. Enable **Anonymous Authentication**, and disable all other authentications.
4. Perform these steps for all sub-applications as well.
**Add properties to the `web.config` files of certain modules**
Certain modules need to have their authentication checked by the special `Advantys.Security.JWTAuthenticationModule` WorkflowGen authentication module, but certain other modules should not because they are either public or aren't part of the global authentication system.
1. Open the WorkflowGen `web.config` file and **add/update** the following property:
```markup
```
2. In the `auth` module's `web.config`, **add/update** the following property:
```markup
```
This line removes the authentication Node.js module from the global authentication system, because this Node.js application encapsulates the OpenID Connect authentication mechanisms.
3. Repeat the above two steps for the `hooks` and `scim` modules as well.
4. Copy the following .NET assemblies and dependency libraries from `\wfgen\bin` to each custom webform's `\bin` folder (`\wfgen\wfapps\webforms\\bin`):
* `Advantys.My.dll`
* `Advantys.Security.dll`
* `Newtonsoft.Json.dll`
* `jose-jwt.dll`
{% hint style="success" %}
You should now have a working WorkflowGen instance with the authentication delegated to Okta through the OpenID Connect protocol. Make sure to have provisioned your users to WorkflowGen in order for them to successfully access WorkflowGen.
{% endhint %}
### Configuring the authentication without the GraphQL API
If for some reason you can't add an authorization server in your Okta account and you don't need GraphQL API authentication configured with the provider, you can avoid creating the server and configure WorkflowGen with the default Okta authorization server.
#### Step 1: Create the WorkflowGen web application
1. Go to the Okta Developer portal.
2. In the **Applications** item under the **Applications** menu, click the **Create App Integration** button.
3. Select the following options in **Create a new app integration**, then click **Next**:
* **Sign-in method:** `OIDC - OpenID Connect`
* **Application type:** `Web Application`
4. Enter the following information:
* **App integration name:** `WorkflowGen`
* **Grant type:** Check `Authorization Code`
* **Sign-in redirect URIs:** `/auth/callback`
* **Sign-out redirect URIs:** `/auth/logout/return`
* **Base URIs:** `` without any path (just the base URL); for example, `https://localhost`, if `` is `https://localhost/wfgen`
* **Controlled access:** Check `Allow everyone in your organization to access`
* Leave the remaining properties set to their defaults.\
\
\
\
5. Click the **Save** button.
6. On the **General** tab of your WorkflowGen web application page, click the **Edit** button in the **General Settings** section.
7. Enter the following information:
* **Initiate login URI**: `/auth/callback`
\
8. Click **Save**.
You've now successfully configured Okta for your WorkflowGen instance.
#### Step 2: Configure WorkflowGen
Add or update the following configuration options in the WorkflowGen `web.config` file.
* Change `MetadataUrl` to `https:///.well-known/openid-configuration`.
* Change `UsernameClaim` to `preferred_username`.
* Change `AuthAudience` to the client ID of the **WorkflowGen** web application configured in Okta.
* Set the `ApplicationSecurityAuthDecodeAccessToken` option to `N`.
{% hint style="warning" %}
* Keep in mind that by setting `ApplicationSecurityAuthDecodeAccessToken=N`, the expiration date of the session token generated by WorkflowGen will be based on that of the ID token.
* You won't be able to use the access token received from Okta to query the GraphQL API. This access token will give you access to the Okta API and nothing else. To query the GraphQL API, you'll need to configure its authentication with another method, like **Basic** authentication.
{% endhint %}
**Classic usage:**
```markup
```
#### Step 3: Add some security values for session generation
In order to generate a session token, you need to add a few more settings to the `web.config` file.
1. Open the WorkflowGen `web.config` file and **add/update** the following property:
```markup
```
2. Replace `` with a value that can't be easily guessed, such as a UUID.
The secret will be only accessible inside your instance of WorkflowGen, so when generating a session token, WorkflowGen will sign it with this secret in order to check the validity of all session tokens passed to it.
#### Step 4: Activate the authentication delegation
You now need to activate the delegation by replacing the authentication system in IIS and pointing WorkflowGen's modules to the correct authentication module.
**Configure IIS**
1. In **IIS Manager**, click on the WorkflowGen application in the tree view.
2. Click the **Authentication** button.
3. Enable **Anonymous Authentication**, and disable all other authentications.
Perform these steps for all sub-applications as well.
**Add properties to the `web.config` files of certain modules**
Certain modules need to have their authentication checked by the special `Advantys.Security.JWTAuthenticationModule` WorkflowGen authentication module, but certain other modules should not because they are either public or aren't part of the global authentication system.
1. Open the WorkflowGen `web.config` file and add/update the following property:
```markup
```
2. In the `auth` module's `web.config`, **add/update** the following property:
```markup
```
This line removes the authentication Node.js module from the global authentication system, because this Node.js application encapsulates the OpenID Connect authentication mechanisms.
3. Repeat the above two steps for the `hooks` and `scim` modules as well.
4. Copy the following .NET assemblies and dependency libraries from `\wfgen\bin` to each custom webform's `\bin` folder (`\wfgen\wfapps\webforms\\bin`):
* `Advantys.My.dll`
* `Advantys.Security.dll`
* `Newtonsoft.Json.dll`
* `jose-jwt.dll`
{% hint style="success" %}
You should now have a working WorkflowGen instance with the authentication delegated to Okta through the OpenID Connect protocol. Make sure to have provisioned your users to WorkflowGen in order for them to successfully access WorkflowGen.
{% endhint %}
## Okta user provisioning
The self-provisioning connector is a directory connector that automatically creates and synchronizes a user based on the user's session token claims that contain claims from the OpenID Connect provider ID token. This feature is only compatible with an OpenID Connect authentication.
### Prerequisites
* Make sure to have a working WorkflowGen instance.
* Make sure to know the instance's IP address or its fully qualified name.
* Make sure to know the address of the instance.
* Make sure to have configured Okta or one of the other OIDC-compliant authentication methods ([Azure Active Directory](https://docs.advantys.com/workflowgen-for-azure/v/8.0.0/), [AD FS](https://advantys.gitbooks.io/workflowgen-technical-reference-guide/content/adfs-integration.html), [Auth0](https://advantys.gitbooks.io/workflowgen-technical-reference-guide/content/auth0-integration), or [Microsoft Identity Platform v2.0](https://docs.advantys.com/workflowgen-for-azure/v/8.0.0/)).
### WorkflowGen configuration
This section will guide you through the WorkflowGen configurations necessary to set up the self-provisioning feature with a directory.
#### Step 1: Create a self-provisioning directory
This directory will contain all of the users that are not provisioned elsewhere. To create a self-provisioning directory, do the following:
1. On the **Directories** page in the WorkflowGen Administration Module, click **New directory**.
2. Fill in the form:
* **Name**: `SELF_PROVISONING`(or something else)
* **Description:** A good description of the directory
* **Directory connector:** `Self-provisioning`
3. Click **Save**.
#### Step 2: Configure the user fields-to-claims mapping
Now that you've created a new directory with the self-provisioning connector, you need to define which claims are mapped to which WorkflowGen user field. To do this:
1. On the new directory's page, click **Edit mapping**.
2. To the right of the name of the WorkflowGen user field, enter the name of the claim in the session token that you want to map.
Here's an example of a session token generated by the `auth` node application from the Okta ID token connected with Google Apps:
```
{
"sub": "some.user@advantys.com",
"iss": "https:///auth",
"aud": "https://",
"exp": 1535627127,
"https://api.workflowgen.com/username": "some.user@advantys.com",
"given_name": "Some",
"family_name": "User",
"nickname": "some-user",
"name": "Some User",
"picture": "https://lh4.googleusercontent.com/path/to/photo.jpg",
"gender": "male",
"locale": "en",
"updated_at": "1970-01-01T00:00:00Z",
"email": "some.user@advantys.com",
"email_verified": true,
"nonce": "ffdd6d95-31e6-4466-84c4-43f8c0fbaae7",
"iat": 1535591128
}
```
These claims could be mapped in WorkflowGen like this:
✏️ **Note:** The **Username** and **Name** fields are required.
3. Click **Save**.
## Okta configuration for WorkflowGen Plus v2
Mobile applications must use an approach similar to that of regular web applications, which is called **Authorization Code Flow with Proof Key for Code Exchange (PKCE)**. The main difference between this and the classic Authorization Code Flow is that the mobile application doesn't get a client secret, but instead exchanges a pair of codes to prove the origin of the authentication attempt. The issue is that a mobile application can't be trusted with a client secret because it's distributed directly to users and is therefore no longer under the developer's control, and the sources can be decompiled and analyzed to find secrets like this.
This section provides instructions on how to configure Okta for mobile apps so that your mobile users can benefit from delegated authentication as well.
### Prerequisites
* Make sure to have a licensed copy of WorkflowGen installed and running on a server.
* Make sure to have administrative access to Okta to be able to configure it properly.
* Make sure to have provisioned an existing Okta user with which you can authenticate to WorkflowGen so that you can use the application afterwards.
* Make sure to have the WorkflowGen Plus mobile application installed on a device that you have access to.
* Make sure to have the latest WorkflowGen Plus version installed on your device and that your device is supported.
* Make sure to have successfully configured delegated authentication to Okta on your WorkflowGen instance following the instructions in the [Okta authentication](#okta-authentication) section.
### Okta configuration
#### Step 1: Create the WorkflowGen Plus native application
1. In your Okta developer portal, go to the **Applications** item under the **Applications** menu, then click the **Create App Integration** button.\
\
2. Select the following options under **Create a new app integration**, then click **Next**:
* **Sign-in method:** `OIDC - OpenID Connect`
* **Application type:** `Native Application`
3. Enter the following information:
* **App integration name:** `WorkflowGen Plus`
* **Grant type**: Check `Authorization Code` and `Refresh Token`
* **Sign-in redirect URIs:** `workflowgenplus://oidc`
* **Sign-out redirect URIs**: `workflowgenplus://oidc`
* **Controlled access:** Check `Allow everyone in your organization to access`
\
\
4. Click the **Save** button.
#### Step 2: Add an Initiate login URI
1. On your Okta **WorkflowGen Plus** native application page, go to the **General Settings** section on the **General** tab, then click the **Edit** button.
2. Enter the following information:
* **Initiate login URI**: `workflowgenplus://oidc`
3. Click **Save**.
### Review the registration
If you've set up delegated authentication to Okta on your WorkflowGen server, you should have an access policy on your Okta WorkflowGen GraphQL API authorization server that will let any configured client access it. Therefore, there's nothing left to do on the Okta side. Here's a review of the information you need:
* A `client ID`, which can be found on the Okta **WorkflowGen Plus** native application page's **Settings** tab.
* Your `Okta domain name` which can be found directly to the left of your profile picture on the top right corner of the page.
{% hint style="success" %}
All of this information must be given to the users who will be using the mobile application; they'll need to copy them directly into the app.
{% endhint %}
## Okta configuration for server-side scripts
In some cases, you'll want to perform a specific task that can be automated but needs access to the WorkflowGen GraphQL API; this use case is often in the form of a server-side script. For this, OAuth2 provides a type of grant called **Client Credentials** that simply exchanges a client ID and secret for an access token. There's no ID token since it's not part of the OpenID Connect standard and there's no user involved.
This section provides instructions on how to configure Okta with a server-side script that has access to the GraphQL API. First, you'll need to configure a new web application in the Okta portal; then, you'll need to configure a new application in WorkflowGen.
### Prerequisites
* Make sure to have a licensed copy of WorkflowGen installed and running on a server.
* Make sure to have administrative access to WorkflowGen.
* Make sure to have administrative access to Okta to be able to configure it properly.
* Make sure to have successfully configured delegated authentication to Okta on your WorkflowGen instance following the instructions in the [Okta authentication](#okta-authentication) section.
### Okta configuration
#### Create a new API services application
1. In the **Applications** item under the **Applications** menu in your Okta developer portal, click the **Create App Integration** button.
2. Select the **API Services** sign-in method, then click **Next**.\
\
3. Enter the name of your application, then click **Save**.\
\
### Review the registration
Here's a review of the information you need:
* A `client ID` and a `client secret`, which can be found on the newly registered service application's **general** tab.
* The WorkflowGen GraphQL API identifier, which can be found on its **settings** page.
### WorkflowGen configuration
As with user provisioning, WorkflowGen needs to know which application is accessing the GraphQL API. Therefore, you have to register the application, which consists of your script.
#### Register a new application
1. On the **Applications** page in the WorkflowGen Administration Module, click **New application**.
2. Fill in the form:
* **Name**: `My API Services App`
* **Description**: A description that clearly identifies the script
* **Type**: `Non-interactive Client`
* **Impersonate username**: Any username that has the required access to the GraphQL API
* **Client ID**: The `client ID` you retrieved earlier from your registered service app (e.g. `My API Services App`)
* **Active**: Check this checkbox
3. Click **Save**.
Your application should now appear in the list of applications.
{% hint style="success" %}
You should now have the necessary components in place to make GraphQL API requests with your script by passing the access token received from Okta from a Client Credentials Grant flow.
{% endhint %}
## Okta configuration for single-page applications
JavaScript applications running in a browser are often hard to secure due to the open nature of the Web. Secure storage is nonexistent, and everything is in clear text (for HTTP version 1.1). Here's a quote from the Azure Active Directory team that summarizes the state of authentication with single-page applications:
> The OAuth2 implicit grant is notorious for being the grant with the longest list of security concerns in the OAuth2 specification. And yet, that is the approach implemented by ADAL JS and the one we recommend when writing SPA applications. What gives? It’s all a matter of tradeoffs: and as it turns out, the implicit grant is the best approach you can pursue for applications that consume a Web API via JavaScript from a browser.
>
> (Source: )
It's therefore important that you make all of the necessary checks to verify the validity of your requests and the responses.
This section provides instructions on how to configure Okta with a single-page application (SPA) so that users can authenticate through it and make requests to the WorkflowGen GraphQL API. This configuration is done in two steps: registering your SPA, then setting some redirect URLs.
### Prerequisites
* Make sure to have a licensed copy of WorkflowGen installed and running on a server.
* Make sure to have administrative access to Okta to be able to configure it properly.
* Make sure to have provisioned an existing Okta user with which you can authenticate to WorkflowGen so that you can use the application afterwards.
* Make sure to have successfully configured delegated authentication to Okta on your WorkflowGen instance following the instructions in the [Okta authentication](#okta-authentication) section.
### Okta configuration
#### Create a new single-page application
1. In your Okta developer portal, go to the **Applications** item under the **Applications** menu, then click the **Create App Integration** button.
2. Select the **OIDC - OpenID Connect** sign-in method, select **Single-Page Application** as the application type, then click **Next**.\
\
3. Enter the following information:
* **App integration name:** `My SPA`, or the name of your single-page application
* **Grant type**: Check `Authorization Code`
* **Sign-in redirect URIs:** The login redirect URI for your single-page application
* **Sign-out redirect URIs**: The logout redirect URI for your single-page application
* **Base URIs:** The base URI of your single-page application
* **Controlled access**: Check `Allow everyone in your organization to access`
4. Click **Save**.
#### Review the registration
* You need a `client ID`, which can be found on the **General** tab on your single-page application page.
{% hint style="success" %}
Your application should now successfully linked to the Okta infrastructure and users can log in through it. If you have met the prerequisites, your application will receive an access token that it can send to the WorkflowGen GraphQL API to make authorized requests as a Bearer token via the `Authorization` header.
{% endhint %}
## Okta configuration for the WorkflowGen CLI
### Interactive mode
#### Create a new native application
1. In your Okta developer portal, go to the **Applications** item under the **Applications** menu, then click **Create App Integration**.
2. Select the **OIDC - OpenID Connect** sign-in method, select **Native Application** as the application type, then click **Next**.\
\
3. Enter the following information:
* **Name:** `WorkflowGen CLI`
* **Grant type:** Check `Authorization Code` and `Refresh token`
* **Sign-in redirect URIs:** Define the URL as `http://127.0.0.1:8888/callback`
✏️ **Note:** Port `8888` is defined by default; you can change it if it's already in use on your computer.
* **Sign-out redirect URIs:** Don't define a URL. Clear the field if there's a default value.
* **Controlled access**: Check `Allow everyone in your organization to access`
\
\
\
4. Click the **Save** button.
#### Review the registration
If you've configured delegated authentication to Okta on your WorkflowGen server, you should have an access policy on your Okta authorization server from the WorkflowGen GraphQL API that will allow all configured users to access it; there's nothing left to do on the Okta side. Here's a summary of the information you'll need:
* A `client ID`, which can be found on the **General** tab on the WorkflowGen CLI native application's page.
* A `metadata endpoint`, which consists of the value of **Metadata URI** property from the **Settings** tab of your WorkflowGen GraphQL API authorization server with `/.well-known/oauth-authorization-server` replaced by `/.well-known/openid-configuration`.
{% hint style="success" %}
All of this information must be given to users who will be using the WorkflowGen CLI.
{% endhint %}
### Non-interactive mode
The configuration of non-interactive mode is the same as in the [Okta configuration for server-side scripts](#okta-configuration-for-server-side-scripts) section.
Here's a review of the information of the information you'll need:
* A `client ID`, which can be found on the registered application's parameters tab.
* A `client secret`, which can be found on the registered application's parameters tab.
* The `domain`, which can be found on the registered application's parameters tab.
{% hint style="success" %}
You can now use the WorkflowGen CLI in `Client credentials` mode.
{% endhint %}
## Generating a universal link for WorkflowGen Plus v2
As of WorkflowGen server version 7.14.0, you can generate a universal link to simplify the Okta login process for your WorkflowGen Plus mobile app users.
#### Base URL
* **protocol:** `workflowgenplus://`
* **hostname:** `auth.init`
#### Parameters
You'll need to specify the following parameters:
* **provider:** `okta`
* **server\_address**: Your WorkflowGen application URL, whose value must be URL encoded (e.g. `https://mycompany.com/wfgen`)
* **client\_id:** Use the `client ID` you created earlier in the configuration (e.g. `0o7gdj4hs92yh7`) from the step [Okta configuration for WorkflowGen Plus v2](#okta-configuration-for-workflowgen-plus-v2).
* **metadata\_url:** The `metadata URL`, which consists of the value of **Metadata URI** property from the **Settings** tab of your WorkflowGen GraphQL API authorization server with `/.well-known/oauth-authorization-server` replaced by `/.well-known/openid-configuration` (e.g. `https://{YOUR_OKTA_DOMAIN}/oauth2/{AUTH_SERVER_ID}/.well-known/openid-configuration`). The value must be URL encoded.
* **audience**: Your WorkflowGen GraphQL API URL, whose value must be URL encoded (e.g. `https://mycompany.com/wfgen/graphql`)
The universal link should follow this format:
```
workflowgenplus://auth.init?provider=okta&server_address=https%3A%2F%2Fmycompany.com%2Fwfgen&client_id=0o7gdj4hs92yh7&metadata_url=https%3A%2F%2F{YOUR_OKTA_DOMAIN}%2Foauth2%2F{AUTH_SERVER_ID}%2F.well-known%2Fopenid-configuration&audience=https%3A%2F%2Fmycompany.com%2Fwfgen%2Fgraphql
```
{% hint style="success" %}
Once you've generated the universal link, give it to your users, who can use it to sign in to WorkflowGen Plus with the preset sign-in method.
{% endhint %}
## Additional information on Okta integration
### WorkflowGen SOAP API services support
WorkflowGen only supports requests to the SOAP API using classic authentication methods. If you still need to use this API, you have to perform some additional steps to configure it properly.
1. Create a new separate WorkflowGen directory for the SOAP API users.
2. Provision it with users and groups as needed.
3. In the **IIS Manager**, enable the **Basic** authentication method for the `\wfgen\ws` application.
4. In the `web.config` file (located in `\Inetpub\wwwroot\wfgen`), add the following under `` :
```markup
```
### Web service type application support
Web service type applications only support requests using classic authentication methods. If you still need to use these APIs, you have to perform some additional steps to configure it properly.
1. Make sure you have a local or domain account provisioned on your WorkflowGen server. (This can be the account you used prior to changing your authentication method to Okta.)
2. In the IIS Manager, enable either the Basic or Windows authentication method for your application (e.g. `wfapps/webservices/myWebService`).
3. In the `web.config` file (located in `\Inetpub\wwwroot\wfgen`), add the following new location under the last location: \
\
``\
\
The structure should be as follows:
```html
```