Skip to content

3.9.2

Release Date: September 16, 2026

🐛 Bug Fixes

Terraform Modules

Fix no OAuth application found with the provided label in saif-resources External Identity 🔐

Module: saif-resources (external-identity module — main.tf)

PR: #1189 (backport of a fix already on main)

Fixes a Terraform apply failure in production deployments:

Error: no OAuth application found with the provided label: clm-api-proc-claim

  with module.saif-appservices.module.external_identity.data.okta_app_oauth.api_app,
  on .terraform/modules/saif-appservices.external_identity/modules/external-identity/main.tf line 38, in data "okta_app_oauth" "api_app":
  38: data "okta_app_oauth" "api_app" {

data.okta_app_oauth.api_app looked the application up by label. The Okta provider implements that argument as a single-result search: it calls ListApplications with limit=1 and the label as the q term, then exact-compares whatever one application comes back. Okta treats q as a case-insensitive startsWith match across both label and name, and returns results sorted by creation date. Any application whose label merely starts with the requested label can therefore consume the only result slot, and the exact-compare then fails even though the correct application exists and is active.

In the reported case, clm-api-proc-claim was shadowed by the earlier-created clm-api-proc-claimintake. Because the outcome depends on application creation order within the Okta org rather than on any Terraform configuration, a workspace that previously applied cleanly can begin failing with no change on our side. Non-production was unaffected because those labels carry an -np suffix, which makes the search term selective enough to avoid the collision.

Upstream tracking: okta/terraform-provider-okta#2847. The generic okta_app data source was fixed for this same bug, but the fix was never propagated to okta_app_oauth or okta_app_saml, and both remain affected as of provider 6.11.0.

Changes:

  • Added data.okta_apps.api_app, which searches with q and active_only and returns the full paginated result set instead of a single record
  • Added local.api_app_matches, which filters that result set down to an exact, case-sensitive label match
  • Changed data.okta_app_oauth.api_app to resolve by id rather than label, which is an unambiguous lookup
  • Added a lifecycle.precondition asserting that exactly one application matches the expected label
  • Documented the failure mode in the module README and in a new troubleshooting article
  • Added tests/validate.tftest.hcl covering the collision case, the non-production -np label, and each precondition failure mode

This mirrors the two-step lookup the same module already used for the front-end application, so both lookups now behave consistently.

Benefits:

  • 🚫 Eliminates no OAuth application found with the provided label failures caused by label prefix collisions
  • 🔒 Prevents a latent credential-crossover risk: an unresolved lookup previously let the provider fall back to listing applications with no search filter and bind an arbitrary one, which would have written another application's client_secret into Key Vault and published the wrong client_id as OAuthClientId_ext
  • 🧭 Fails fast with an explicit, actionable message instead of silently selecting the wrong application
  • ✅ Verified against the affected production workspace, where the lookup now resolves to the correct application

Action required:

Keep the bounded constraint (~> 3.9.0), run terraform init -upgrade to pick up 3.9.2, then re-apply. No module inputs or outputs changed, and no state operations are required.

🔄 Breaking Changes

None in this release ✅

📋 Additional Notes

  • Total commits: 1 (backported from main)
  • Files changed: 4
  • Contributors: Emmitt Johnson

Support

  • 📧 Teams Support Channel: Support