fix: consistently handle string-valued boolean fields from non-compliant OIDC providers

[bashhack]

Background

👋 @muhlemmer - hope all is well with you and the team!

AWS Cognito (and potentially other providers) return email_verified and phone_number_verified as strings ("true"/"false") instead of proper JSON booleans, violating the OIDC specification.

AWS Documentation confirms this:

Currently, Amazon Cognito returns the values for email_verified and phone_number_verified as strings.

Source: https://docs.aws.amazon.com/cognito/latest/developerguide/userinfo-endpoint.html#get-userinfo-response-sample

The Problem

The zitadel/oidc library currently handles this inconsistently:

• ✅ EmailVerified uses the custom Bool type (added in feat: Enable parsing email_verified from string. #139)
• ❌ PhoneNumberVerified uses Go's standard bool

This forces developers to handle semantically identical fields differently:

// Currently inconsistent code path
userInfo.EmailVerified = oidc.Bool(emailValue)    // Cast
userInfo.PhoneNumberVerified = phoneValue      // No cast

Additionally, the existing Bool.UnmarshalJSON implementation meant that false values couldn't overwrite true.

Solution

Applied Bool type consistently to both fields and simplified Bool.UnmarshalJSON using a direct switch statement to:

• Handle standard JSON booleans (true/false)
• Handle AWS Cognito string format ("true"/"false")
• Return errors on invalid input instead of silently failing
• Allow false to overwrite true

Updated tests to match codebase conventions, as well.

Impact

PhoneNumberVerified changes from bool to Bool (type alias of bool). Most consumer code should work as-is since Bool is just a type alias. Direct type assertions would need updating.

Definition of Ready

• I am happy with the code
• Short description of the feature/issue is added in the pr description
• PR is linked to the corresponding user story
• Acceptance criteria are met
• All open todos and follow ups are defined in a new ticket and justified
• Deviations from the acceptance criteria and design are agreed with the PO and documented.
• No debug or dead code
• My code has no repetitions
• Critical parts are tested automatically
• Where possible E2E tests are implemented
• Documentation/examples are up-to-date
• All non-functional requirements are met
• Functionality of the acceptance criteria is checked manually on the dev system.

[muhlemmer]

Breaking Changes

Please don't use this string in your PR comment. It get's converted to the commit message later and it will trigger the semrel tool to create a new major release.

[elinashoko]

Heyo @bashhack checking if you'll have some time to come back to this PR?

[bashhack]

@elinashoko - yeah! Been swamped on my end, but should have time by end of this weekend to wrap this up - thanks for being so patient all 🤝

[bashhack]

@muhlemmer + @elinashoko - should be all set here, I think the end approach is a nice balance, thanks again! PR feedback implemented, and branch updated accordingly with main 🤝

Congrats on the 1.25+ support, too! 🎉

[elinashoko]

Thank you kindly @bashhack
@muhlemmer please have another look when you have a sec.

[muhlemmer]

One more small comment and we are good to merge.

[muhlemmer]

No need to link the PR. If people want to find the source of a change, they can git blame.

Suggested change

	//
	// For broader historical context, see:
	// - https://github.com/zitadel/oidc/pull/139

[elinashoko]

@bashhack pls have a look when you have a chance, let's get this over the line!