okta_app_oauth - remove force_new?

[exitcode0]

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

Description

okta_app_oauth uses force_new to taint the resource if omit_secret ever changes from false -> True
I'm wondering if we need to do this given that a while ago Okta added the capability for Applications to have multiple credentials to improve the experience when rotating credentials

Now that this is available, we can potentially avoid re-creating the application and rotating the application's id and instead replace the client_secret with a new randomly generated client_secret, then we don't persist this new secret's value to state

If we avoid re-creating the entire application, we likely reduce our exposure to eventual consistency in the Okta API

Perhaps instead the client secrets should be separated into their own discrete resource? 🤔 💭

New or Affected Resource(s)

• okta_app_oauth
• okta_client_secret
• okta_app_oauth_client_secret

References

• https://developer.okta.com/docs/reference/api/apps/#add-new-client-secret
• https://developer.okta.com/docs/reference/api/apps/#delete-a-client-secret
• https://developer.okta.com/docs/reference/api/apps/#activate-a-client-secret
• https://developer.okta.com/docs/reference/api/apps/#deactivate-a-client-secret
• Tgoodsell tempus 1852 #1888
• Okta App OAuth: Make Omit Secret Safer To Set #1852

[exitcode0]

CC: @tgoodsell-tempus
given you raised #1852 you likely have some context / more informed opinions here

[duytiennguyen-okta]

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

[tgoodsell-tempus]

CC: @tgoodsell-tempus given you raised #1852 you likely have some context / more informed opinions here

The issue we have is the apps API still supports the legacy method for controlling the client secret, which only supports a single secret string. This support likely just needs to be removed entirely, and swapped over to the new API which supports the multiple secret option as a new standalone resource.