コンテンツにスキップ
Kong Logo | Kong Docs Logo
  • ドキュメント
    • API仕様を確認する
      View all API Specs すべてのAPI仕様を表示 View all API Specs arrow image
    • ドキュメンテーション
      API Specs
      Kong Gateway
      軽量、高速、柔軟なクラウドネイティブAPIゲートウェイ
      Kong Konnect
      SaaSのエンドツーエンド接続のための単一プラットフォーム
      Kong AI Gateway
      GenAI インフラストラクチャ向けマルチ LLM AI Gateway
      Kong Mesh
      Kuma と Envoy をベースにしたエンタープライズサービスメッシュ
      decK
      Kongの構成を宣言型で管理する上で役立ちます
      Kong Ingress Controller
      Kubernetesクラスタ内で動作し、Kongをプロキシトラフィックに設定する
      Kong Gateway Operator
      YAMLマニフェストを使用してKubernetes上のKongデプロイメントを管理する
      Insomnia
      コラボレーティブAPI開発プラットフォーム
  • Plugin Hub
    • Plugin Hubを探索する
      View all plugins すべてのプラグインを表示 View all plugins arrow image
    • 機能性 すべて表示 View all arrow image
      すべてのプラグインを表示
      AI's icon
      AI
      マルチ LLM AI Gatewayプラグインを使用してAIトラフィックを管理、保護、制御する
      認証's icon
      認証
      認証レイヤーでサービスを保護する
      セキュリティ's icon
      セキュリティ
      追加のセキュリティレイヤーでサービスを保護する
      トラフィック制御's icon
      トラフィック制御
      インバウンドおよびアウトバウンドAPIトラフィックの管理、スロットル、制限
      サーバーレス's icon
      サーバーレス
      他のプラグインと組み合わせてサーバーレス関数を呼び出します
      分析と監視's icon
      分析と監視
      APIとマイクロサービストラフィックを視覚化、検査、監視
      変革's icon
      変革
      Kongでリクエストとレスポンスをその場で変換
      ログ記録's icon
      ログ記録
      インフラストラクチャに最適なトランスポートを使用して、リクエストと応答データをログに記録します
  • サポート
  • コミュニティ
  • Kongアカデミー
デモを見る 無料トライアルを開始
Kong Konnect
  • Home icon
  • Kong Konnect
  • Org Management
  • Configure SSO with Okta
report-issue問題を報告する
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Kong AI Gateway
  • Plugin Hub
  • decK
  • Kong Ingress Controller
  • Kong Gateway Operator
  • Insomnia
  • Kuma

  • ドキュメント投稿ガイドライン
  • Introduction
    • Overview of Konnect
    • Architecture
    • Network Resiliency and Availability
    • Port and Network Requirements
    • Private Connections to Other Cloud Providers
      • Create a private connection with AWS PrivateLink
    • Geographic Regions
    • Centralized consumer management
    • Compatibility
    • Stages of Software Availability
    • Release Notes
    • Support
      • Control Plane Upgrades FAQ
      • Supported Installation Options
  • Get Started
    • Overview
    • Add your API
    • Migrating a Self-Managed Kong Gateway into Konnect
  • Gateway Manager
    • Overview
    • Dedicated Cloud Gateways
      • Overview
      • Provision a Dedicated Cloud Gateway
      • Securing Backend Traffic
      • Transit Gateways
      • Azure VNET Peering
      • Custom Domains
      • Custom Plugins
      • Data plane logs
    • Serverless Gateways
      • Overview
      • Provision a serverless Gateway
      • Securing Backend Traffic
      • Custom Domains
    • Data Plane Nodes
      • Installation Options
      • Upgrade a Data Plane Node
      • Verify a Data Plane Node
      • Secure Control Plane/Data Plane Communications
      • Renew Data Plane Certificates
      • Parameter Reference
      • Using Custom DP Labels
    • Control Plane Groups
      • Overview
      • Working with Control Plane Groups
      • Migrate Configuration into Control Plane Groups
      • Conflicts in Control Planes
    • Kong Gateway Configuration in Konnect
      • Overview
      • Manage Plugins
        • Overview
        • Adding Custom Plugins
        • Updating Custom Plugins
        • How to Create Custom Plugins
      • Create Consumer Groups
      • Secrets Management
        • Overview
        • Konnect Config Store
        • Set Up and Use a Vault in Konnect
      • Manage Control Plane Configuration with decK
    • Active Tracing
      • Overview
    • KIC Association
    • Backup and Restore
    • Version Compatibility
    • Troubleshooting
  • Mesh Manager
    • Overview
    • Create a mesh with the Kubernetes demo app
    • Federate a zone control plane to Konnect
    • Migrate a self-managed zone control plane to Konnect
  • Service Catalog
    • Overview
    • Integrations
      • Overview
      • Datadog
      • GitHub
      • GitLab
      • PagerDuty
      • SwaggerHub
      • Traceable
      • Slack
    • Scorecards
  • API Products
    • Overview
    • Product Documentation
    • Productize a Service
  • Dev Portal
    • Overview
    • Dev Portal Configuration Preparation
    • Create a Dev Portal
    • Sign Up for a Dev Portal Account
    • Publish an API to Dev Portal
    • Access and Approval
      • Manage Developer Access
      • Manage Developer Team Access
      • Add Developer Teams from IdPs
      • Manage Application Registrations
      • Configure generic SSO for Dev Portal
      • Configure Okta SSO for Dev Portal
    • Application Lifecycle
    • Register and create an application as a developer
    • Enable and Disable App Registration for API Product Versions
    • Dynamic Client Registration
      • Overview
      • Okta
      • Curity
      • Auth0
      • Azure
      • Custom IdP
    • Portal Management API Automation Guide
    • Audit Logging
      • Overview
      • Set up an Audit Log Webhook
      • Set up an Audit Log Replay Job
    • Portal Customization
      • Overview
      • About Self-Hosted Dev Portal
      • Host your Dev Portal with Netlify
      • Custom Domains
    • Dev Portal SDK
    • Troubleshoot
  • Advanced Analytics
    • Overview
    • Dashboard
    • Explorer
    • Analyze API Usage and Performance with Reports
    • Requests
  • Org Management
    • Plans and Billing
    • Authentication and Authorization
      • Overview
      • Teams
        • Overview
        • Manage Teams
        • Teams Reference
        • Roles Reference
      • Manage Users
      • Manage System Accounts
      • Personal Access Tokens
      • Social Identity Login
      • Org Switcher
      • Configure Generic SSO
      • Configure Okta SSO
      • Login Sessions Reference
      • Troubleshoot
    • Audit Logging
      • Overview
      • Set up an Audit Log Webhook
      • Set up an Audit Log Replay Job
    • Account and Org Deactivation
  • API
    • Overview
    • API Request API (Beta)
      • API Spec
    • API Products API
      • API Spec
    • Audit Logs API
      • API Spec
      • Audit Log Webhooks
    • Control Plane API
      • API Spec
    • Control Plane Configuration API
      • API Spec
    • Cloud Gateways API
      • API Spec
    • Identity API
      • API Spec
      • Identity Integration Guide
      • SSO Customization
    • Konnect Search API (Beta)
      • API Spec
    • Mesh Manager API
      • API Spec
      • Kong Mesh API Reference
    • Portal Client API
      • API Spec
    • Portal Management API
      • API Spec
    • Reference
      • Filtering
      • API Errors
  • Reference
    • Labels
    • Plugin Ordering Reference
    • Konnect Search
    • Terraform Provider
    • Audit Logs
    • Verify audit log signatures
    • IdP SAML attribute mapping
enterprise-switcher-icon 次に切り替える: OSS
On this pageOn this page
  • Prerequisites
  • Configure an Okta Application
  • Set up Konnect
    • Configure Okta connection details
    • Okta users and mapping groups to Konnect teams
  • Debug and test the configuration
  • (Optional) Enable Kong Konnect as a dashboard app in Okta
  • Okta reference docs

このページは、まだ日本語ではご利用いただけません。翻訳中です。

Configure SSO with Okta
Available with Kong Gateway Enterprise subscription - Contact Sales

Kong Konnect provides built-in authentication, allowing you to setup users and teams for Konnect authentication and authorization. Alternatively, you can set up single sign-on (SSO) access to Konnect using OpenID Connect (OIDC) or Security Assertion Markup Language (SAML). These authentication methods allow your users to log in to Konnect using IdP authorization, without needing additional Konnect specific credentials. You can also configure a mapping between Okta group claims and Kong Konnect teams, allowing for Konnect user team assignments from within Okta.

This topic provides specific instructions for configuring SSO with Okta. See Configure Generic SSO for general instructions on setting up SSO for other identity providers.

It is recommended to use a single authentication method, however, Konnect supports the ability to combine built-in authentication with either OIDC or SAML based SSO. Combining both OIDC and SAML based SSO is not supported. Keep built-in authentication enabled while you are testing IdP authentication and only disable it after successfully testing your SSO configuration.

Prerequisites

  • An Okta account with administrator access to configure Applications and Authorization Server settings.
  • A non-public Kong Konnect Dev Portal created in your Konnect organization.

Configure an Okta Application

OIDC
SAML
  1. From the Applications section of the Okta console, select Create App Integration and choose OIDC - OpenID Connect with Web Application for the Application type. Provide the following configuration details:
    • Grant type: Authorization Code
    • Sign-in redirect URIs: https://cloud.konghq.com/login
    • Sign-out redirect URIs: https://cloud.konghq.com/login
  2. Optional: If you want to map Okta group claims to Konnect Organization Teams, modify the OpenID Connect ID Token claims in the Application->Sign On section of the Okta configuration, setting the following values:

    • Group claims type: Filter
    • Group claims filter: Enter groups for the claim name and enter Matches regex as the filter type and .* for the filter value.

    This claim specifies which user’s groups to include in the token, in this case the wildcard regex specifies that all groups will be included.

    If the authorization server is retrieving additional groups from third-party applications (for example, Google groups), the groups claim will not contain them. If it is desired to use these third-party groups, the Okta administrator will need to duplicate them directly in Okta or use a custom token to include them in the groups claim.

  3. Assign desired groups and users to the new Okta application.

  4. Locate the following values in the Okta console, which will be used later for the Konnect configuration.

    • Client ID: Located in your Application General -> Client Credentials settings.
    • Client Secret: Located in your Application General -> Client Secrets settings.
    • Issuer URI : The Issuer is typically found in the Security -> API -> Authorization Servers settings. It should look like the following: https://<okta-org-id>.okta.com/oauth2/default
  1. From the Applications section of the Okta console, select Create App Integration and choose SAML 2.0. Provide the following configuration details:
    • Give the application a name that signifies it is for Konnect SAML SSO.

    • Single Sign-On URL: https://global.api.konghq.com/v2/authenticate/login_path/saml/acs

    • Audience URI (SP Entity ID): https://cloud.konghq.com/sp/SP_ID

  2. Optional: To include additional user attributes beyond authentication, add the following three attributes in the Attribute Statements:

    Name Name format Value
    firstName Unspecified user.firstName
    lastName Unspecified user.lastName
    email Unspecified user.email
  3. Generate a signing certificate to use in Konnect.

  4. Assign desired groups and users to the new Okta application.

Set up Konnect

Configure Okta connection details

OIDC
SAML
  1. In Konnect, navigate to organizations icon Organization -> Settings and then the Authentication Scheme tab.

  2. Select the Configure option for OIDC.

  3. Insert your Issuer URI, Client ID and Client Secret in the OIDC configuration fields.

  4. In the Organization Login Path field, enter a value that uniquely identifies your organization. This path value will be used by Konnect to route users to the correct organization login page.

    Requirements:

    • The path must be unique across all Konnect organizations. If your desired path is already taken, you will be prompted to enter another one.
    • The path can be any alphanumeric string.
    • The path does not require a slash (/).
  5. Under Advanced Settings, specify the Scopes Konnect requests from Okta. The openid scope is required for OIDC authentication. The profile and email scopes are recommended so Konnect obtains the user’s name and email address in the token response.

  6. In the Claim Mappings section, set the values of each field to their appropriate token response field name. Use the Okta Token Preview feature to verify the response token field names will match what you enter in these mappings. The default values are as follows:

    • Name: name
    • Email: email
    • Groups: groups
  7. Save the configuration and then select Enable OIDC.

  1. In Kong Konnect, click organizations icon Organization > Settings, and then click the Authentication Scheme tab.

  2. Click Configure for SAML.

  3. In Okta, go to Sign On page in the Okta application created in the previous step and copy the IDP Metadata URL under the Settings section. It should look like: https://<okta-org-id>.okta.com/app/exkgzjkl0kUZB06Ky5d7/sso/saml/metadata

  4. In the Organization Login Path field, enter a value that uniquely identifies your organization. This path value will be used by Konnect to route users to the correct organization login page.

    Requirements:

    • The path must be unique across all Konnect organizations. If your desired path is already taken, you will be prompted to enter another one.
    • The path can be any alphanumeric string.
    • The path does not require a slash (/).
  5. Save this configuration, Konnect will generate two new values. A Single Sign-On URL and an Audience URI.

  6. In the Okta console, update the previous placeholder Single Sign-On URL and Audience URI (SP Entity ID) with the new values generated by Konnect.

  7. In Konnect, close the configuration dialog and click Enable SAML from the context menu.

Okta users and mapping groups to Konnect teams

While it is not required, it is recommended to use Konnect’s Okta group to team mapping feature. If you choose not to use this feature then approving new users will require a two step process. First, the user will need to login to Konnect with their Okta credentials. They will receive an access error but the new user will be visible to the Konnect administrator. The administrator can now map the user to a valid Konnect team, which will give the user the required access. The new user must now re-login to gain access.

Preferably the IdP group to team mapping feature is used to streamline this process. Use the following to enable this feature:

  1. In Konnect, go to organizations icon Organization > Settings, click the Team Mappings and enable the IdP Mapping feature.

    Each Konnect team can be mapped to one Okta group.

    For example, if you have a service_admin group in Okta, you might map it to the Service Admin team in Konnect. You can hover over the info (i) icon beside each field to learn more about the team, or see the teams reference for more information.

    You must have at least one group mapped to save configuration changes.

  2. Click Save.

After mapping is set up:

  • Okta users belonging to the mapped groups can log in to Konnect.
  • When a user logs into Konnect with their Okta account for the first time, Konnect automatically provisions an account with the relevant roles.
  • If your org already has non-admin Konnect users before mapping, on their next login they will be mapped to the teams defined by their Okta group membership.
  • An organization admin can view all registered users in Konnect, but cannot edit their team membership from the Konnect side. To manage automatically-created users, adjust user permissions through Okta, or adjust the team mapping.

Any changes to the mapped Okta groups on the Okta side are reflected in Konnect. For example:

  • Removing a user from a group in Okta also deactivates their Konnect account.
  • Moving a user from one group to another changes their team in Konnect to align with the new group-to-team mapping.

Debug and test the configuration

The Okta console provides a Token Preview feature which will be useful in verifying configuration values for these SSO configuration instructions. If you encounter issues configuring SSO with Okta, start by checking the Token Preview for the Okta application you created.

Test the SSO configuration by navigating to the login URI based on the organization login path you set earlier. For example, if you successfully configured a login path of examplepath, navigate to https://cloud.konghq.com/login/examplepath. Attempt to login with an Okta user assigned to your new application. If authorization is successful and the team configuration is correct, the user should be able to access the Konnect organization.

(Optional) Enable Kong Konnect as a dashboard app in Okta

If you want your users to have easy access to Kong Konnect alongside their other apps, you can add it to your Okta dashboard.

In Okta, navigate to the General Settings of your application and configure the application icon for users as needed.

Okta reference docs

  • Build an Okta SSO integration
  • Create claims in Okta
  • Groups claim
  • Custom claims
Thank you for your feedback.
Was this page useful?
情報が多すぎる場合 close cta icon
Kong Konnectを使用すると、より多くの機能とより少ないインフラストラクチャを実現できます。月額1Mリクエストが無料。
無料でお試しください
  • Kong
    APIの世界を動かす

    APIマネジメント、サービスメッシュ、イングレスコントローラーの統合プラットフォームにより、開発者の生産性、セキュリティ、パフォーマンスを大幅に向上します。

    • 製品
      • Kong Konnect
      • Kong Gateway Enterprise
      • Kong Gateway
      • Kong Mesh
      • Kong Ingress Controller
      • Kong Insomnia
      • 製品アップデート
      • 始める
    • ドキュメンテーション
      • Kong Konnectドキュメント
      • Kong Gatewayドキュメント
      • Kong Meshドキュメント
      • Kong Insomniaドキュメント
      • Kong Konnect Plugin Hub
    • オープンソース
      • Kong Gateway
      • Kuma
      • Insomnia
      • Kongコミュニティ
    • 会社概要
      • Kongについて
      • お客様
      • キャリア
      • プレス
      • イベント
      • お問い合わせ
  • 利用規約• プライバシー• 信頼とコンプライアンス
© Kong Inc. 2025