Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[DX-1535] OKTA DCR #5878

Merged
merged 2 commits into from
Jan 23, 2025
Merged

[DX-1535] OKTA DCR #5878

merged 2 commits into from
Jan 23, 2025

Conversation

sharadregoti
Copy link
Contributor

@sharadregoti sharadregoti commented Jan 8, 2025 •
edited
Loading

User description

For internal users - Please add a Jira DX PR ticket to the subject!


Preview Link


https://deploy-preview-5878--tyk-docs.netlify.app/docs/nightly/tyk-stack/tyk-developer-portal/enterprise-developer-portal/api-access/dynamic-client-registration/

Description


Screenshots (if appropriate)


Checklist

  • I have added a preview link to the PR description.
  • I have reviewed the suggestions made by our AI (PR Agent) and updated them accordingly (spelling errors, rephrasing, etc.)
  • I have reviewed the guidelines for contributing to this repository.
  • I have read the technical guidelines for contributing to this repository.
  • Make sure you have started your change off our latest master.
  • I labeled the PR

PR Type

Documentation

Description

  • Added Okta-specific instructions for Dynamic Client Registration (DCR).

  • Enhanced documentation with tabbed examples for Keycloak and Okta.

  • Updated images and steps for creating scopes, policies, and configurations.

  • Improved clarity and structure of DCR flow setup instructions.

Changes walkthrough 📝

Relevant files
Documentation
dynamic-client-registration.md
Add Okta-specific details and improve DCR documentation   

tyk-docs/content/tyk-stack/tyk-developer-portal/enterprise-developer-portal/api-access/dynamic-client-registration.md

  • Added Okta-specific instructions for DCR setup.
  • Introduced tabbed examples for Keycloak and Okta.
  • Updated steps and images for creating scopes and policies.
  • Enhanced clarity and structure of DCR flow documentation.
    		• +128/-41

    💡 PR-Agent usage: Comment /help "your question" on any pull request to receive relevant information

    @github-actions GitHub Actions
    Copy link
    Contributor

    github-actions bot commented Jan 8, 2025

    PR Reviewer Guide 🔍

    Here are some key observations to aid the review process:

    ⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪
    🧪 No relevant tests
    🔒 No security concerns identified
    ⚡ Recommended focus areas for review

    Documentation Clarity

    The added content introduces multiple tabs for Keycloak and Okta configurations. Ensure that the instructions are clear, concise, and consistent across both tabs to avoid confusion for users.

    ### Create OAuth2.0 scopes to enforce access control and rate limit

Tyk uses OAuth2.0 scope to enforce access control and rate limit for API Products. Therefore, creating at least two scopes for an API Product and plan is required. 

The below example demonstrates how to achieve that with Keycloak and Okta in the tabs below.

{{< tabs_start >}}
{{< tab_start "Keycloak" >}}

1. **Navigate to the Client scopes menu item**

    {{< img src="/img/dashboard/portal-management/enterprise-portal/step-1-navigate-to-the-client-scopes-menu.png" alt="Navigate to the Client scopes menu item" >}}

2. **Create a scope for an API Product**

    {{< img src="/img/dashboard/portal-management/enterprise-portal/step-2-create-a-scope-for-an-api-product.png" alt="Create a scope for an API Product" >}}

3. **Create a scope for a plan**

    {{< img src="/img/dashboard/portal-management/enterprise-portal/step-3-create-a-scope-for-a-plan.png" alt="Create a scope for a plan" >}}

{{< note success >}}
**Note**

When using Keycloak, ensure that you set the type of the scope to be `Optional`. Default scopes are applied automatically, while optional scopes can be requested by clients on a case-by-case basis to extend the permissions granted by the user. In recent versions of Keycloak this should appear as a dropdown menu option, as shown in the images above. In older releases of Keycloak this may need to be set explicitly in a separate tab, as show on the image below.
{{< /note >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/old-keycloak-version-client-scope.png" alt="Client Scope Assigned Type" >}}

{{< tab_end >}}

{{< tab_start "Okta" >}}

1. **Create an auth server or use the `Default` authorization server**

    Go to Security → API, Edit one of the auth servers and navigate to `Scopes`

    {{< img src="/img/dashboard/portal-management/enterprise-portal/okta-api-page.png" alt="Add or Edit oauth servers in okta" >}}

2. **Create a scope for an API Product**

    {{< img src="/img/dashboard/portal-management/enterprise-portal/okta-product-payment.png" alt="Create a scope for an API Product" >}}

3. **Create a scope for a plan**

    {{< img src="/img/dashboard/portal-management/enterprise-portal/okta-free-plan-scope.png" alt="Create a scope for a plan" >}}

{{< tab_end >}}

{{< tabs_end >}}

### Create Tyk policies for an API Product and plan

Navigate to the Tyk Dashboard and create two policies: one for a plan and one for an API Product. Both policies should include only the APIs with JWT authentication that you want to bundle as an API Product.

1. **Create a policy for an API product.** 

    {{< img src="/img/dashboard/portal-management/enterprise-portal/create-jwt-policy-for-product.png" alt="Create a policy for a product" >}}

2. **Create a policy for a plan.** 

    {{< img src="/img/dashboard/portal-management/enterprise-portal/create-jwt-policy-for-plan.png" alt="Create a policy for a plan" >}}


### Create the No Operation policy and API
Tyk requires any API that uses the scope to policy mapping to have [a default policy]({{< ref "/api-management/client-authentication#use-json-web-tokens-jwt" >}} ). Access rights and rate limits defined in the default policy take priority over other policies, including policies for the API Product and plan.

To avoid that, you need to create the No Operation API and policy that won't grant access to the APIs included in the API Product but will satisfy the requirement for a default policy.

1. **Create the No Operation API.** 

    Navigate to the `APIs` menu in the Tyk Dashboard:
    {{< img src="/img/dashboard/portal-management/enterprise-portal/navigate-to-the-api-menu-in-the-tyk-dashboard.png" alt="Navigate to the API menu in the Tyk Dashboard" >}}


    Create a new HTTP API:
    {{< img src="/img/dashboard/portal-management/enterprise-portal/create-noop-api.png" alt="Create the No Operation API" >}}


    Save it:
    {{< img src="/img/dashboard/portal-management/enterprise-portal/save-the-noop-api.png" alt="Save the No Operation API" >}}

<br/>

2. **Create the No Operation policy.** 

    Navigate to the `Policies` menu in the Tyk Dashboard:
    {{< img src="/img/dashboard/portal-management/enterprise-portal/navigate-to-the-policies-menu.png" alt="Navigate to the policies menu" >}}

    Create a new policy and select the No Operation API in the `Add API Access Rights` section:
    {{< img src="/img/dashboard/portal-management/enterprise-portal/create-noop-policy.png" alt="Create the No Operation policy" >}}

    Configure the No Operation policy and save it:
    {{< img src="/img/dashboard/portal-management/enterprise-portal/save-the-noop-policy.png" alt="Save the No Operation policy" >}}

### Configure scope to policy mapping

To enforce policies for the API Product and plan, you need to configure the scope to policy mapping for each API included in the API Product.
To achieve that, perform the following steps for each API included in the API Product.

1. Navigate to the API.

    {{< img src="/img/dashboard/portal-management/enterprise-portal/navigate-to-the-api.png" alt="Navigate to the API" >}}

2. Select the required JWT signing method. In this example, we use RSA. Leave the `Public key` and `pol` fields blank, they will be filled automatically by the Enterprise portal.

    {{< img src="/img/dashboard/portal-management/enterprise-portal/select-signing-method.png" alt="Select signing method for the API" >}}

3. Select the No Operation policy as the default policy for this API.

    {{< img src="/img/dashboard/portal-management/enterprise-portal/select-the-default-policy.png" alt="Select the default policy for the API" >}}

4. Enable scope to policy mapping and specify the value of the JWT claim used to extract scopes in the `Scope name` field (the default value is "scope").

    {{< img src="/img/dashboard/portal-management/enterprise-portal/enable-scope-to-policy-mapping.png" alt="Enable scope to policy mapping" >}}


5. Add a scope to policy mapping for the product scope. Type the product scope in the `Claim field` and select the product policy.

    {{< img src="/img/dashboard/portal-management/enterprise-portal/add-a-scope-to-policy-mapping-for-the-product-scope.png" alt="Add scope to policy mapping for the product scope" >}}

6. Add a scope to policy mapping for the plan scope. Type the plan scope in the `Claim field` and select the plan policy, then save the API.

    {{< img src="/img/dashboard/portal-management/enterprise-portal/add-a-scope-to-policy-mapping-for-the-plan-scope.png" alt="Add scope to policy mapping for the plan scope" >}}

## Configure Tyk Enterprise Developer Portal to work with an identity provider

Once policies for the plan and product are created, and the scope-to-policy mapping is configured for all APIs that are included in the product, it's time to set up the portal to work with your IdP.


### Configure the App registration settings

In the portal, navigate to the `OAuth2.0 Providers` menu section. In that section, you need to configure the connection settings to the IdP and define one or more types (configurations) of OAuth 2.0 clients. For instance, you can define two types of OAuth 2.0 clients:
* A confidential client that supports the Client credential grant type for backend integrations;
* A web client that supports the Authorization code grant type for integration with web applications that can't keep the client secret confidential.

Each configuration of OAuth 2.0 client could be associated with one or multiple API Products so that when an API Consumer requests access to an API Product, they can select a client type that is more suitable for their use case.


#### Specify connection setting to your IdP

To connect the portal to the IdP, you need to specify the following settings:
* OIDC well-known configuration URL.
* Initial access token.

First of all, select your IdP from the `Identity provider` dropdown list. Different IdPs have slightly different approaches to DCR implementation, so the portal will use a driver that is specific to your IdP. If your IdP is not present in the dropdown list, select the `Other` option. In that case, the portal will use the most standard implementation of the DCR driver, which implements the DCR flow as defined in the RFC.

Then you need to specify the connection settings: [the initial access token and the well-known endpoint]({{< ref "tyk-stack/tyk-developer-portal/enterprise-developer-portal/api-access/dynamic-client-registration#create-an-initial-access-token" >}}). If your Identity Provider uses certificates that are not trusted, the portal will not work with it by default. To bypass certificate verification, you can select the `SSL secure skip verify` checkbox.

The below example demonstrates how to achieve that with Keycloak and Okta in the tabs below.

{{< tabs_start >}}

{{< tab_start "Keycloak" >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/specify-connection-setting-to-your-idp.png" alt="Specify connection setting to the IdP" >}}

{{< tab_end >}}

{{< tab_start "Okta" >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/specify-connection-setting-to-your-idp-okta.png" alt="Specify connection setting to the IdP" >}}

**OIDC URL**: {your-domain.com}/oauth2/default/.well-known/openid-configuration

**Registration Access Token**: To obtain token, Go to Okta Admin Console → Security → API → Tokens → Create New Token

{{< tab_end >}}

{{< tabs_end >}}

#### Create client configurations
Once the connection settings are specified, you need to create one or multiple types of clients. You might have multiple types of clients that are suitable for different use cases, such as backend integration or web applications.

You need at least one type of client for the DCR flow to work. To add the first client type, scroll down to the `Client Types` section and click on the `Add client type` button.

To configure a client type, you need to specify the following settings:
* **Client type display name.** This name will be displayed to API consumers when they check out API products. Try to make it descriptive and short, so it's easier for API consumers to understand.
* **Description.** A more verbose description of a client type can be provided in this field. By default, we do not display this on the checkout page, but you can customize the respective template and make the description visible to API consumers. Please refer to [the customization section]({{< ref "tyk-stack/tyk-developer-portal/enterprise-developer-portal/customise-enterprise-portal/full-customisation/full-customisation" >}}) for guidance.
* **Allowed response_types.** Response types associated with this type of client as per [the OIDC spec](https://openid.net/specs/openid-connect-core-1_0-17.html).
* **Allowed grant_types.** Grant types that this type of client will support as per [the OIDC spec](https://openid.net/specs/openid-connect-core-1_0-17.html).
* **Token endpoint auth methods.** The token endpoint that will be used by this type of client as per [the OIDC spec](https://openid.net/specs/openid-connect-core-1_0-17.html).
* Additionally, there’s an additional field for Okta: **Okta application type** which defines which type of Okta client should be created. Ignored for all other IdPs.

Please note that your IdP might override some of these settings based on its configuration.

The below example demonstrates how to achieve that with Keycloak and Okta in the tabs below. After configuring a client type, scroll to the top of the page to save it by clicking on the `SAVE CHANGES` button.

{{< tabs_start >}}

{{< tab_start "Keycloak" >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/configure-type-of-client.png" alt="Configure a client type" >}}

{{< tab_end >}}

{{< tab_start "Okta" >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/configure-type-of-client-okta.png" alt="Configure a client type" >}}

**For Okta Client Credentials**: allowed response types MUST be token only

{{< tab_end >}}

{{< tabs_end >}}

### Configure API Products and plans for the DCR flow
Once the App registration settings are configured, it is time for the final step: to configure the API Products and plans to work with the DCR flow.

#### Configure API Products for the DCR flow
To configure API Products to work with the DCR flow, you need to:
* Enable the DCR flow for the products you want to work with the DCR flow.
* Associate each product with one or multiple types of clients that were created in the previous step.
* Specify scopes for this API Product. Note the portal uses the scope to policy mapping to enforce access control to API Products, so there should be at least one scope.

For achieving this, navigate to the `API Products` menu and select the particular API product you want to use for the DCR flow. Next, go to the ‘App registration configs’ section and enable the ‘Enable dynamic client registration’ checkbox.

After that, specify the scope for this API product. You should have at least one scope that was created in [the Prerequisites for getting started]({{< ref "tyk-stack/tyk-developer-portal/enterprise-developer-portal/api-access/dynamic-client-registration#prerequisites-for-getting-started" >}}). If you need to specify more than one scope, you can separate them with spaces.

Finally, select one or multiple types of clients that were created in [the Create client configurations]({{< ref "tyk-stack/tyk-developer-portal/enterprise-developer-portal/api-access/dynamic-client-registration#create-client-configurations" >}}) section of this guide to associate them with that product.

{{< tabs_start >}}

{{< tab_start "Keycloak" >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/configure-api-products-for-the-dcr-flow.png" alt="Configure an API Product to work with the DCR flow" >}}

{{< tab_end >}}

{{< tab_start "Okta" >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/configure-api-products-for-the-dcr-flow-okta.png" alt="Configure an API Product to work with the DCR flow" >}}

{{< tab_end >}}

{{< tabs_end >}}


#### Configure plans for the DCR flow
The last step is to configure the plans you want to use with the DCR flow. To do this, go to the portal's `Plans` menu section and specify the OAuth2.0 scope to use with each plan. You should have at least one scope that was created in [the Prerequisites for getting started]({{< ref "tyk-stack/tyk-developer-portal/enterprise-developer-portal/api-access/dynamic-client-registration#prerequisites-for-getting-started" >}}). If you need to specify more than one scope, you can separate them with spaces.
    Image Accessibility

    Multiple images have been added to the documentation. Verify that all images are correctly linked, have appropriate alt text, and are accessible to users with visual impairments.

        {{< img src="/img/dashboard/portal-management/enterprise-portal/step-1-navigate-to-the-client-scopes-menu.png" alt="Navigate to the Client scopes menu item" >}}

2. **Create a scope for an API Product**

    {{< img src="/img/dashboard/portal-management/enterprise-portal/step-2-create-a-scope-for-an-api-product.png" alt="Create a scope for an API Product" >}}

3. **Create a scope for a plan**

    {{< img src="/img/dashboard/portal-management/enterprise-portal/step-3-create-a-scope-for-a-plan.png" alt="Create a scope for a plan" >}}

{{< note success >}}
**Note**

When using Keycloak, ensure that you set the type of the scope to be `Optional`. Default scopes are applied automatically, while optional scopes can be requested by clients on a case-by-case basis to extend the permissions granted by the user. In recent versions of Keycloak this should appear as a dropdown menu option, as shown in the images above. In older releases of Keycloak this may need to be set explicitly in a separate tab, as show on the image below.
{{< /note >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/old-keycloak-version-client-scope.png" alt="Client Scope Assigned Type" >}}

{{< tab_end >}}

{{< tab_start "Okta" >}}

1. **Create an auth server or use the `Default` authorization server**

    Go to Security → API, Edit one of the auth servers and navigate to `Scopes`

    {{< img src="/img/dashboard/portal-management/enterprise-portal/okta-api-page.png" alt="Add or Edit oauth servers in okta" >}}

2. **Create a scope for an API Product**

    {{< img src="/img/dashboard/portal-management/enterprise-portal/okta-product-payment.png" alt="Create a scope for an API Product" >}}

3. **Create a scope for a plan**

    {{< img src="/img/dashboard/portal-management/enterprise-portal/okta-free-plan-scope.png" alt="Create a scope for a plan" >}}

{{< tab_end >}}

{{< tabs_end >}}

### Create Tyk policies for an API Product and plan

Navigate to the Tyk Dashboard and create two policies: one for a plan and one for an API Product. Both policies should include only the APIs with JWT authentication that you want to bundle as an API Product.

1. **Create a policy for an API product.** 

    {{< img src="/img/dashboard/portal-management/enterprise-portal/create-jwt-policy-for-product.png" alt="Create a policy for a product" >}}

2. **Create a policy for a plan.** 

    {{< img src="/img/dashboard/portal-management/enterprise-portal/create-jwt-policy-for-plan.png" alt="Create a policy for a plan" >}}


### Create the No Operation policy and API
Tyk requires any API that uses the scope to policy mapping to have [a default policy]({{< ref "/api-management/client-authentication#use-json-web-tokens-jwt" >}} ). Access rights and rate limits defined in the default policy take priority over other policies, including policies for the API Product and plan.

To avoid that, you need to create the No Operation API and policy that won't grant access to the APIs included in the API Product but will satisfy the requirement for a default policy.

1. **Create the No Operation API.** 

    Navigate to the `APIs` menu in the Tyk Dashboard:
    {{< img src="/img/dashboard/portal-management/enterprise-portal/navigate-to-the-api-menu-in-the-tyk-dashboard.png" alt="Navigate to the API menu in the Tyk Dashboard" >}}


    Create a new HTTP API:
    {{< img src="/img/dashboard/portal-management/enterprise-portal/create-noop-api.png" alt="Create the No Operation API" >}}


    Save it:
    {{< img src="/img/dashboard/portal-management/enterprise-portal/save-the-noop-api.png" alt="Save the No Operation API" >}}

<br/>

2. **Create the No Operation policy.** 

    Navigate to the `Policies` menu in the Tyk Dashboard:
    {{< img src="/img/dashboard/portal-management/enterprise-portal/navigate-to-the-policies-menu.png" alt="Navigate to the policies menu" >}}

    Create a new policy and select the No Operation API in the `Add API Access Rights` section:
    {{< img src="/img/dashboard/portal-management/enterprise-portal/create-noop-policy.png" alt="Create the No Operation policy" >}}

    Configure the No Operation policy and save it:
    {{< img src="/img/dashboard/portal-management/enterprise-portal/save-the-noop-policy.png" alt="Save the No Operation policy" >}}

### Configure scope to policy mapping

To enforce policies for the API Product and plan, you need to configure the scope to policy mapping for each API included in the API Product.
To achieve that, perform the following steps for each API included in the API Product.

1. Navigate to the API.

    {{< img src="/img/dashboard/portal-management/enterprise-portal/navigate-to-the-api.png" alt="Navigate to the API" >}}

2. Select the required JWT signing method. In this example, we use RSA. Leave the `Public key` and `pol` fields blank, they will be filled automatically by the Enterprise portal.

    {{< img src="/img/dashboard/portal-management/enterprise-portal/select-signing-method.png" alt="Select signing method for the API" >}}

3. Select the No Operation policy as the default policy for this API.

    {{< img src="/img/dashboard/portal-management/enterprise-portal/select-the-default-policy.png" alt="Select the default policy for the API" >}}

4. Enable scope to policy mapping and specify the value of the JWT claim used to extract scopes in the `Scope name` field (the default value is "scope").

    {{< img src="/img/dashboard/portal-management/enterprise-portal/enable-scope-to-policy-mapping.png" alt="Enable scope to policy mapping" >}}


5. Add a scope to policy mapping for the product scope. Type the product scope in the `Claim field` and select the product policy.

    {{< img src="/img/dashboard/portal-management/enterprise-portal/add-a-scope-to-policy-mapping-for-the-product-scope.png" alt="Add scope to policy mapping for the product scope" >}}

6. Add a scope to policy mapping for the plan scope. Type the plan scope in the `Claim field` and select the plan policy, then save the API.

    {{< img src="/img/dashboard/portal-management/enterprise-portal/add-a-scope-to-policy-mapping-for-the-plan-scope.png" alt="Add scope to policy mapping for the plan scope" >}}

## Configure Tyk Enterprise Developer Portal to work with an identity provider

Once policies for the plan and product are created, and the scope-to-policy mapping is configured for all APIs that are included in the product, it's time to set up the portal to work with your IdP.


### Configure the App registration settings

In the portal, navigate to the `OAuth2.0 Providers` menu section. In that section, you need to configure the connection settings to the IdP and define one or more types (configurations) of OAuth 2.0 clients. For instance, you can define two types of OAuth 2.0 clients:
* A confidential client that supports the Client credential grant type for backend integrations;
* A web client that supports the Authorization code grant type for integration with web applications that can't keep the client secret confidential.

Each configuration of OAuth 2.0 client could be associated with one or multiple API Products so that when an API Consumer requests access to an API Product, they can select a client type that is more suitable for their use case.


#### Specify connection setting to your IdP

To connect the portal to the IdP, you need to specify the following settings:
* OIDC well-known configuration URL.
* Initial access token.

First of all, select your IdP from the `Identity provider` dropdown list. Different IdPs have slightly different approaches to DCR implementation, so the portal will use a driver that is specific to your IdP. If your IdP is not present in the dropdown list, select the `Other` option. In that case, the portal will use the most standard implementation of the DCR driver, which implements the DCR flow as defined in the RFC.

Then you need to specify the connection settings: [the initial access token and the well-known endpoint]({{< ref "tyk-stack/tyk-developer-portal/enterprise-developer-portal/api-access/dynamic-client-registration#create-an-initial-access-token" >}}). If your Identity Provider uses certificates that are not trusted, the portal will not work with it by default. To bypass certificate verification, you can select the `SSL secure skip verify` checkbox.

The below example demonstrates how to achieve that with Keycloak and Okta in the tabs below.

{{< tabs_start >}}

{{< tab_start "Keycloak" >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/specify-connection-setting-to-your-idp.png" alt="Specify connection setting to the IdP" >}}

{{< tab_end >}}

{{< tab_start "Okta" >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/specify-connection-setting-to-your-idp-okta.png" alt="Specify connection setting to the IdP" >}}

**OIDC URL**: {your-domain.com}/oauth2/default/.well-known/openid-configuration

**Registration Access Token**: To obtain token, Go to Okta Admin Console → Security → API → Tokens → Create New Token

{{< tab_end >}}

{{< tabs_end >}}

#### Create client configurations
Once the connection settings are specified, you need to create one or multiple types of clients. You might have multiple types of clients that are suitable for different use cases, such as backend integration or web applications.

You need at least one type of client for the DCR flow to work. To add the first client type, scroll down to the `Client Types` section and click on the `Add client type` button.

To configure a client type, you need to specify the following settings:
* **Client type display name.** This name will be displayed to API consumers when they check out API products. Try to make it descriptive and short, so it's easier for API consumers to understand.
* **Description.** A more verbose description of a client type can be provided in this field. By default, we do not display this on the checkout page, but you can customize the respective template and make the description visible to API consumers. Please refer to [the customization section]({{< ref "tyk-stack/tyk-developer-portal/enterprise-developer-portal/customise-enterprise-portal/full-customisation/full-customisation" >}}) for guidance.
* **Allowed response_types.** Response types associated with this type of client as per [the OIDC spec](https://openid.net/specs/openid-connect-core-1_0-17.html).
* **Allowed grant_types.** Grant types that this type of client will support as per [the OIDC spec](https://openid.net/specs/openid-connect-core-1_0-17.html).
* **Token endpoint auth methods.** The token endpoint that will be used by this type of client as per [the OIDC spec](https://openid.net/specs/openid-connect-core-1_0-17.html).
* Additionally, there’s an additional field for Okta: **Okta application type** which defines which type of Okta client should be created. Ignored for all other IdPs.

Please note that your IdP might override some of these settings based on its configuration.

The below example demonstrates how to achieve that with Keycloak and Okta in the tabs below. After configuring a client type, scroll to the top of the page to save it by clicking on the `SAVE CHANGES` button.

{{< tabs_start >}}

{{< tab_start "Keycloak" >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/configure-type-of-client.png" alt="Configure a client type" >}}

{{< tab_end >}}

{{< tab_start "Okta" >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/configure-type-of-client-okta.png" alt="Configure a client type" >}}

**For Okta Client Credentials**: allowed response types MUST be token only

{{< tab_end >}}

{{< tabs_end >}}

### Configure API Products and plans for the DCR flow
Once the App registration settings are configured, it is time for the final step: to configure the API Products and plans to work with the DCR flow.

#### Configure API Products for the DCR flow
To configure API Products to work with the DCR flow, you need to:
* Enable the DCR flow for the products you want to work with the DCR flow.
* Associate each product with one or multiple types of clients that were created in the previous step.
* Specify scopes for this API Product. Note the portal uses the scope to policy mapping to enforce access control to API Products, so there should be at least one scope.

For achieving this, navigate to the `API Products` menu and select the particular API product you want to use for the DCR flow. Next, go to the ‘App registration configs’ section and enable the ‘Enable dynamic client registration’ checkbox.

After that, specify the scope for this API product. You should have at least one scope that was created in [the Prerequisites for getting started]({{< ref "tyk-stack/tyk-developer-portal/enterprise-developer-portal/api-access/dynamic-client-registration#prerequisites-for-getting-started" >}}). If you need to specify more than one scope, you can separate them with spaces.

Finally, select one or multiple types of clients that were created in [the Create client configurations]({{< ref "tyk-stack/tyk-developer-portal/enterprise-developer-portal/api-access/dynamic-client-registration#create-client-configurations" >}}) section of this guide to associate them with that product.

{{< tabs_start >}}

{{< tab_start "Keycloak" >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/configure-api-products-for-the-dcr-flow.png" alt="Configure an API Product to work with the DCR flow" >}}

{{< tab_end >}}

{{< tab_start "Okta" >}}

{{< img src="/img/dashboard/portal-management/enterprise-portal/configure-api-products-for-the-dcr-flow-okta.png" alt="Configure an API Product to work with the DCR flow" >}}

{{< tab_end >}}

{{< tabs_end >}}

    @github-actions GitHub Actions
    Copy link
    Contributor

    github-actions bot commented Jan 8, 2025

    PR Code Suggestions ✨

    No code suggestions found for the PR.

    @netlify Netlify
    Copy link

    netlify bot commented Jan 8, 2025 •
    edited
    Loading

    ✅ PS. Pls add /docs/nightly to the end of url

    Name Link
    🔨 Latest commit c26f277
    🔍 Latest deploy log https://app.netlify.com/sites/tyk-docs/deploys/6791e8e03bb42a0008261554
    😎 Deploy Preview https://deploy-preview-5878--tyk-docs.netlify.app
    📱 Preview on mobile
    Toggle QR Code...

    QR Code

    Use your smartphone camera to open QR code link.

    To edit notification comments on pull requests, go to your Netlify site configuration.

    @sharadregoti sharadregoti changed the title OKTA DCR [DX-1535] OKTA DCR Jan 8, 2025
    @sharadregoti sharadregoti requested review from JRWu and andrestyk January 8, 2025 11:32
    @sharadregoti sharadregoti merged commit 97e95ae into master Jan 23, 2025
    9 checks passed
    @sharadregoti sharadregoti deleted the okta-dcr branch January 23, 2025 07:08
    @sharadregoti
    Copy link
    Contributor Author

    /release to release-5.7

    @tykbot tykbot
    Copy link

    tykbot bot commented Jan 23, 2025

    Working on it! Note that it can take a few minutes.

    tykbot bot pushed a commit that referenced this pull request Jan 23, 2025
    @sharadregoti
    [DX-1535] OKTA DCR (#5878)
    0ff4e3f 
    (cherry picked from commit 97e95ae)
    @buger buger mentioned this pull request Jan 23, 2025
    Merged
    @tykbot tykbot
    Copy link

    tykbot bot commented Jan 23, 2025

    @sharadregoti Succesfully merged PR

    buger added a commit that referenced this pull request Jan 23, 2025
    @buger
    Merging to release-5.7: [DX-1535] OKTA DCR (#5878)
    c5fc212 
    [DX-1535] OKTA DCR (#5878)
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Reviewers

    @andrestyk andrestyk andrestyk approved these changes

    @JRWu JRWu Awaiting requested review from JRWu

    Assignees
    No one assigned
    Labels
    Review effort [1-5]: 4
    Projects
    None yet
    Milestone
    No milestone
    Development

    Successfully merging this pull request may close these issues.
    2 participants
    @sharadregoti @andrestyk