Tags: zitadel/oidc
Tags
fix: grant type in device code validation error message (#845) Use `GrantTypeDeviceCode` in device code error message The error message was incorrectly referencing `GrantTypeCode`(authorization_code) instead of `GrantTypeDeviceCode` when validation failed.
fix: consistently handle string-valued boolean fields from non-compli… …ant OIDC providers (#791) 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](https://openid.net/specs/openid-connect-basic-1_0.html#StandardClaims). 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 #139) - ❌ `PhoneNumberVerified` uses Go's standard `bool` This forces developers to handle semantically identical fields differently: ```go // 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 - [X] I am happy with the code - [X] Short description of the feature/issue is added in the pr description - [ ] PR is linked to the corresponding user story - [X] 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. - [X] No debug or dead code - [X] My code has no repetitions - [X] Critical parts are tested automatically - [x] Where possible E2E tests are implemented - [X] Documentation/examples are up-to-date - [ ] All non-functional requirements are met - [x] Functionality of the acceptance criteria is checked manually on the dev system. Co-authored-by: Wim Van Laer <wim07101993@users.noreply.github.com>
fix!: allow expires to be an integer wrapped in a string value (#821) Certain providers, for example Entra ID, return durations as quoted strings instead of JSON numbers. This is a deviation from the standard. This change allows for the successful parsing of such quoted duration strings. BREAKING CHANGE: The `expires_in field` has changed from type `int64` to `oidc.Duration` for various token response payloads. fixes #815 ### Definition of Ready - [x] I am happy with the code - [x] Short description of the feature/issue is added in the pr description - [x] PR is linked to the corresponding user story - [x] Acceptance criteria are met - [x] 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. - [x] No debug or dead code - [x] My code has no repetitions - [x] 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.
fix(rp): don't ignore JWKS parsing errors (#771) This safely ignores unknown key type errors on JWKS while returning all other errors. Returned errors are wrap to easily identify which key in the set is problematic if any. Jose v4.0.3 was handling this correctly according to spec, but it was reverted in v4.0.4 as the implementation was a breaking change due to the custom UnmarshalJSON on the key set. For details see: - go-jose/go-jose#136 - go-jose/go-jose#137 Jose v4.0.4 also provided a handy static error to check for unknown web key types. Sadly this was removed: a prefix match on the error message is the best option until Jose improves it's error handling. Hopefully, Jose will not change the error message in a patch or minor version release. But just in case, test cases have been added to detect it. Closes #541 ### Definition of Ready - [x] I am happy with the code - [x] Short description of the feature/issue is added in the pr description - [x] 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. - [x] No debug or dead code - [x] My code has no repetitions - [x] Critical parts are tested automatically - [x] Where possible E2E tests are implemented - [x] Documentation/examples are up-to-date - [x] All non-functional requirements are met - [ ] Functionality of the acceptance criteria is checked manually on the dev system. Co-authored-by: Wim Van Laer <wim07101993@users.noreply.github.com>
feat(rp): add WithPKCEFromDisocvery (#776) Add the WithPKCEFromDiscovery option to create a relying party with PKCE enabled if it is supported when query the discovery endpoint as discussed in #506. This only works when creating an OIDC RP which performs a discovery call. With an OAuth2-only RP, an error is returned as no discovery call is performed. Closes #506 ### Definition of Ready - [x] I am happy with the code - [x] Short description of the feature/issue is added in the pr description - [x] 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. - [x] No debug or dead code - [x] My code has no repetitions - [x] Critical parts are tested automatically - [x] Where possible E2E tests are implemented - [x] Documentation/examples are up-to-date - [x] All non-functional requirements are met - [ ] Functionality of the acceptance criteria is checked manually on the dev system.
feat: allow setting op.Crypto during provider setup (#778) Add a `op.WithCrypto` `op.Option` that allows developers to specify their custom `op.Crypto` implementations during setup. If the `op.Option` is used, it will override `op.Config.CryptoKey`. Closes #736. ### Definition of Ready - [x] I am happy with the code - [x] Short description of the feature/issue is added in the pr description - [x] 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. - [x] No debug or dead code - [ ] My code has no repetitions - [ ] Critical parts are tested automatically - [ ] Where possible E2E tests are implemented - [x] Documentation/examples are up-to-date - [ ] All non-functional requirements are met - [ ] Functionality of the acceptance criteria is checked manually on the dev system. --------- Signed-off-by: mqf20 <mingqingfoo@gmail.com> Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
fix: add redirect_uri decoded (#775) ### Definition of Ready This PR introduces a redirect_uri decoding step (url.QueryUnescape) in the authorization request validation logic. Libraries such as [golang.org/x/oauth2](https://cs.opensource.google/go/x/oauth2/+/refs/tags/v0.30.0:oauth2.go;l=184) automatically encode the redirect_uri using url.Values.Encode(). This means the incoming URI is percent-encoded (e.g., https%3A%2F%2Fclient.example.com%2Fcallback), and the server must decode it before performing string comparisons. - [x] I am happy with the code - [x] Short description of the feature/issue is added in the pr description - [x] PR is linked to the corresponding user story - [x] Acceptance criteria are met - [x] All open todos and follow ups are defined in a new ticket and justified - [x] Deviations from the acceptance criteria and design are agreed with the PO and documented. - [x] No debug or dead code - [x] My code has no repetitions - [x] Critical parts are tested automatically - [x] Where possible E2E tests are implemented - [x] Documentation/examples are up-to-date - [x] All non-functional requirements are met - [x] Functionality of the acceptance criteria is checked manually on the dev system. Co-authored-by: sianao <me@sianao.site>
feat(rp): optional authorized party check (#752) This PR makes the default Authorized Party check in `rp.VerifyIDToken` optional by adding an options parameter for dynamic verification functions. This check is meant to be an optional validation requirement, so some providers (including GCP) do not adhere to it. See #405 for more context. Closes #405
feat: pass optional logout hint and ui locales to end session request (… …#774) ### Definition of Ready - [x] I am happy with the code - [x] Short description of the feature/issue is added in the pr description - [x] PR is linked to the corresponding user story - [x] Acceptance criteria are met - [x] All open todos and follow ups are defined in a new ticket and justified - [x] Deviations from the acceptance criteria and design are agreed with the PO and documented. - [x] No debug or dead code - [x] My code has no repetitions - [x] Critical parts are tested automatically - [x] Where possible E2E tests are implemented - [x] Documentation/examples are up-to-date - [x] All non-functional requirements are met - [x] Functionality of the acceptance criteria is checked manually on the dev system. # Context PR #754 has introduced the optional logout hint and UI locales to the end session request. However, while working on zitadel/zitadel#10039 , I have noticed that the integration tests on Zitadel side call `relying_party.EndSession()` without the possibility of specifying any logout hint nor ui locales. This PR adds these 2 parameters to `relying_party.EndSession()` function.
PreviousNext