Okta Terraform Provider

When managing OAuth client secrets, you have three options depending on your Terraform version and security requirements:

1. client_basic_secret (Sensitive): The standard way to provide a secret. Warning: This secret will be stored in plain text in your Terraform state file.
2. client_basic_secret_wo (Sensitive, Write-Only): Available for Terraform 1.11+. This is the recommended approach as it does not persist the secret in the Terraform state file. You can use client_basic_secret_wo_version (a number) to trigger an update when changing the secret.
3. omit_secret (Boolean): If set to true, the provider will not manage the client_secret value in state. This prevents the auto-generated secret from being persisted in the client_secret attribute.

Important: You can specify either client_basic_secret or client_basic_secret_wo, but not both. If you change omit_secret from false to true, the secret is dropped from state. If you change it from true to false, the application will be recreated because a new secret must be generated to be stored in state.

The okta_policy_rule_profile_enrollment resource is used to update the default rule of a Profile Enrollment Policy.

Important Constraints:

• Identity Engine Only: This feature is only available as part of the Okta Identity Engine (OIE).
• Single Rule Limitation: A profile enrollment policy is limited to exactly one default rule. This resource does not create a new rule; instead, it allows you to update the existing default rule for a given policy.

To use this resource, you must have an existing okta_policy_profile_enrollment policy ID.

resource "okta_policy_rule_profile_enrollment" "example" {
  policy_id           = okta_policy_profile_enrollment.example.id
  inline_hook_id      = okta_inline_hook.example.id
  target_group_id     = okta_group.example.id
  unknown_user_action = "REGISTER"
  email_verification  = true
  access              = "ALLOW"
  profile_attributes {
    name     = "email"
    label    = "Email"
    required = true
  }
  profile_attributes {
    name     = "name"
    label    = "Name"
    required = true
  }
  profile_attributes {
    name     = "t-shirt"
    label    = "T-Shirt Size"
    required = false
  }
}

You can configure a rule to select an IdP dynamically using Okta Expression Language. This is achieved by setting selection_type to DYNAMIC and providing a provider_expression.

When selection_type is DYNAMIC:

• provider_expression: An Okta Expression Language expression evaluated against the Login Context (e.g., login.identifier.substringAfter('@')).
• property_name: The IdP property to match the evaluated expression against.
• should_fall_back_to_okta: A boolean specifying whether to fall back to Okta if authentication with the matched IdP fails. Defaults to false.

resource "okta_policy_rule_idp_discovery" "dynamic_example" {
  policy_id           = data.okta_policy.idp_discovery_policy.id
  name                = "dynamic-idp-routing"
  network_connection  = "ANYWHERE"
  priority            = 2
  status              = "ACTIVE"
  selection_type      = "DYNAMIC"
  provider_expression = "login.identifier.substringAfter('@')"
}

To implement an OIE-based MFA policy, set is_oie = true. This allows you to use OIE-specific authenticators such as okta_verify and custom_app.

For custom_app, you must provide a list of maps containing the id (the custom app ID) and the enroll status. For external_idps, you can define multiple external identity providers with their respective enrollment settings.

resource "okta_policy_mfa" "oie_example" {
  name        = "MFA Policy OIE"
  status      = "ACTIVE"
  description = "Example MFA policy that uses Okta Identity Engine (OIE) with authenticators"
  is_oie      = true

  okta_password = {
    enroll = "REQUIRED"
  }

  okta_verify = {
    enroll = "REQUIRED"
  }

  custom_app = [
    { "enroll" : "OPTIONAL", "id" : "aut123456789abcdef" },
    { "enroll" : "OPTIONAL", "id" : "aut123456789ghijkl" }
  ]

  groups_included = ["${data.okta_group.everyone.id}"]
}