You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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? 🤔 💭
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.
Community Note
Description
okta_app_oauth
usesforce_new
to taint the resource ifomit_secret
ever changes fromfalse -> 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 stateIf 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)
References
The text was updated successfully, but these errors were encountered: