-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resetting/rotating client secrets not behaving as expected #1769
Comments
Looking at the API docs - I think this would require a new resource perhaps It'd make sense to me to add this for SAML apps as well |
OKTA internal reference https://oktainc.atlassian.net/browse/OKTA-658715 |
Thanks for reviewing this @exitcode0 and @duytiennguyen-okta! I gave this some thought last night after I submitted it. I agree that breaking out client secrets into a new resource may be the most "correct" way to do this. I also thought adding a new number argument to the Putting that logic in a new resource that allows tainting and better management makes sense though! |
I think allowing two secrets on the resource as @ChrisAtHashiCorp suggests is the way to go. It's only additive behavior and @duytiennguyen-okta @exitcode0 what do you think? |
I think this approach makes sense and is likely the quickest way to solve this right now I think that I'd like to eventually see us use a separate resource for app credentials as I think this better aligns with the Terraform best practice of one resource, one api endpoint |
I agree here, based on the API docs: https://developer.okta.com/docs/reference/api/apps/#application-client-secret-management-operations This definitely should be split out into its own resource, since these do now have things like a unique ID, a active/inactive status, and other things which means the behavior has more nuance that what is currently supported. Additionally, we should have the next "breaking release" remove the ability to manage the secrets inside of the |
Great work here team, I truly appreciate it! This request came from a shared customer of ours. Not sure what the best way to name drop them is. I can send one of y'all an email with some details around this request if you'd like so you can tag them in your internal tracker. What's the best way to ship y'all this information? |
@monde The only thing I'd warn against here is I'm unsure that the standard CRUD API call for |
Evidence for the above:
Since the Therefore, it seems more prudent to just go the "new resource" route and start deprecating the direct secret management on the |
FYI, I created this PR which hopefully helps improve the use of Long term, for me, the only real answer is removing all of this and making that new secrets API the only way to manage these things, as the current way |
Community Note
Terraform Version
Terraform v1.4.6
on linux_amd64
Affected Resource(s)
Terraform Configuration Files
Expected Behavior
Client secrets should be rotated by following the documentation located here:
https://registry.terraform.io/providers/okta/okta/latest/docs/resources/app_oauth#resetting-client-secret
Can this be done in the Admin UI?
Yes
Can this be done in the actual API call?
Yes
Actual Behavior
The resource gets tainted and is destroyed and rebuilt.
Steps to Reproduce
Follow the documentation located here:
https://registry.terraform.io/providers/okta/okta/latest/docs/resources/app_oauth#resetting-client-secret
terraform apply
The results:
Request
There should be a way to create and rotate application client secrets from Terraform (that doesn't involve destroying and rebuilding the resource). It would be nice to possibly be able to create two client secrets for an OAuth app so there can be a grace period while downstream applications are updated with the new client secret: https://developer.okta.com/docs/guides/client-secret-rotation-key/main/#rotate-a-client-secret
The text was updated successfully, but these errors were encountered: