feat(cognito): support SecretValue for UserPoolIdentityProviderOidc

[jwoehrle]

Issue # (if applicable)

Closes #29851

Reason for this change

Support SecretValue for UserPoolIdentityProviderOidc.

Description of changes

Added optional support for SecretValue to UserPoolIdentityProviderOidc.

Description of how you validated changes

Yes, see packages/aws-cdk-lib/aws-cognito/test/user-pool-idps/oidc.test.ts#L229

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 7b060e8
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[paulhcsun]

Hi @jwoehrle, thanks for making this contribution!

This change definitely brings this contract more in line with what we prefer in terms of accepting objects instead of strings, however it also makes the contract more complicated because we would need to maintain both of these paths until cdk v3 and having both properties as optional becomes a confusing DX.

This is not an incorrect change by any means and we would definitely want to update this property when cdk v3 eventually happens, but after discussing with the team I don't think we are willing to accept this improvement due due to the tradeoffs that come with it at this time.

I can't think of any other ways to make this change without making both properties optional other than using a feature flag but we try to avoid adding new feature flags as much as possible as it makes our code messier and harder to maintain. I'm open to any other alternative suggestions if you have any, but otherwise we will close this PR and I'll update the original issue.

[aws-cdk-automation]

This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week.

[aws-cdk-automation]

This PR has been deemed to be abandoned, and will be automatically closed. Please create a new PR for these changes if you think this decision has been made in error.

[aws-cdk-automation]

The pull request linter fails with the following errors:

❌ Features must contain a change to a README file.
❌ Features must contain a change to an integration test file and the resulting snapshot.

PRs must pass status checks before we can provide a meaningful review.

If you would like to request an exemption from the status checks or clarification on feedback, please leave a comment on this PR containing Exemption Request and/or Clarification Request.

[clayrosenthal]

@paulhcsun
If this is messy here, why isn't it messy in the google provider? It's the same logic in both. Would refactoring the logic into a helper function so its DRY make this an acceptable solution?