OpenID Connect with Okta

Authenticate browser clients using Okta.

The following configuration example allows users to authenticate and access the upstream service even though no Consumer was created for them. This means any user with a valid account in the directory will have access. If you want to restrict access further, you have several options:

  • Consumer mapping: If you need to interact with other Kong Gateway plugins using Consumer information, you can map account data received from the IdP to a Kong Gateway Consumer. See OIDC with Consumer authorization.
  • Pseudo-Consumer mapping: For plugins that typically require Consumers, the OIDC plugin can provide a Consumer ID based on the value of a claim without mapping to an actual Consumer. Setting credential_claim to a claim in your plugin configuration extracts the value of that claim and uses it where Kong Gateway would normally use a Consumer ID. Similarly, setting authenticated_groups_claim extracts that claim’s value and uses it as a group for the ACL plugin.

Prerequisites

  • A developer account with Okta.

  • A Gateway Service and Route secured with HTTPS.

  • A registered application in Okta pointing to the Kong Gateway Route.

  • Any network access control to your Kong Gateway node must allow traffic to and from Okta, the upstream service, and the client.

Environment variables

  • ISSUER: The issuer authentication URL for your IdP. For Okta, that typically looks like this: https://{oktaDomain}/oauth2/{authServer}/.well-known/openid-configuration.

  • CLIENT_ID: The client ID that the plugin uses when it calls authenticated endpoints of the IdP.

  • CLIENT_SECRET: The client secret needed to connect to your IdP.

  • REDIRECT_URI: The redirect_uri of the client defined with client_id.

Set up the plugin

Something wrong?

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!