okta_authenticator fails for key = "webauthn" since 4.8.0

[wrprice]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v1.6.1

• provider registry.terraform.io/okta/okta v4.8.0

Affected Resource(s)

• okta_authenticator

Terraform Configuration Files

resource "okta_authenticator" "webauthn" {
  name   = "FIDO2 (WebAuthn)"
  key    = "webauthn"
  status = "ACTIVE"
}

Expected Behavior

Webauthn authenticator is enabled for the org.

Can this be done in the Admin UI?

Yes

Can this be done in the actual API call?

Yes

Actual Behavior

With the above resource already deployed and in the TF state from a previous version (4.5.0), after upgrading to 4.8.0 the plan shows a diff:

 okta_authenticator.webauthn
-    name = "Security Key or Biometric"
+    name = "FIDO2 (WebAuthn)"

And when apply runs, this error occurs:

Error: for authenticator type 'security_key' fields 'provider_hostname', 'provider_auth_port', 'provider_shared_secret' and 'provider_user_name_template' are required

These settings should NOT be required for FIDO2/WebAuthn, but key = "webauthn" appears to be treated as a security_key type because only that type is required to provide those fields per the provider docs.

Steps to Reproduce

1. Apply configuration shown above using provider <= 4.7.0
2. Upgrade Okta provider to version 4.8.0
3. terraform apply

Important Factoids

Plans and apply run in Terraform Cloud.

References

• enable custom OTP on okta_authenticator #1864
• Isaacokta 1864 #1908

[duytiennguyen-okta]

OKTA internal reference https://oktainc.atlassian.net/browse/OKTA-705810

[duytiennguyen-okta]

@wrprice this should be fixed with v4.8.1

[ejchun]

We're still running into this issue with v4.9.0.

[brandenwagner]

We're still running into this issue with v4.9.0.

Same here with v4.9.1