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 https://github.com/zitadel/oidc/issues/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>
### 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>
### Context
While implementing the Storage interface, I discovered that several
parameter names were misleading:
- Parameters named `refreshTokenID` and `newRefreshTokenID` actually
contain the full token values, not IDs
- This naming inconsistency caused confusion about what values should be
passed/returned
- The example implementations already use the semantically correct names
(`refreshToken`, `newRefreshToken`), creating a mismatch with the
interface definition
## Solution
This PR aligns the interface parameter names with their actual purpose
and with the existing example implementations.
## Changes
1. **Storage interface parameter renames:**
- `TokenRequestByRefreshToken`: `refreshTokenID` → `refreshToken`
- `CreateAccessAndRefreshTokens`: `newRefreshTokenID` →
`newRefreshToken`
2. **Improved code readability in token.go:**
- Made bare returns explicit for better clarity
- Added documentation explaining the token creation flow
- Clarified why `CreateAccessToken` also returns refresh tokens
## Impact
- **Breaking change**: No - these are parameter name changes in the
interface definition only
- **Behavior change**: No - all logic remains unchanged
- **Documentation**: Improved with clearer parameter names and added
explanations
## Testing
- Ran existing tests (some timing-related test failures are pre-existing
and unrelated to these changes)
- Verified example implementations already use the new parameter names
### 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
- [ ] 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
- [ ] 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.
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 https://github.com/zitadel/oidc/issues/405 for more context.
Closes https://github.com/zitadel/oidc/issues/405
### 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 https://github.com/zitadel/oidc/pull/754 has introduced the optional
logout hint and UI locales to the end session request. However, while
working on https://github.com/zitadel/zitadel/pull/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.
Bumps [golang.org/x/text](https://github.com/golang/text) from 0.26.0 to
0.27.0.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="b6d26456dd"><code>b6d2645</code></a>
go.mod: update golang.org/x dependencies</li>
<li>See full diff in <a
href="https://github.com/golang/text/compare/v0.26.0...v0.27.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* pkg/http: Add `secureCookieFunc` field to CookieHandler.
Signed-off-by: Mark Laing <mark.laing@canonical.com>
* pkg/http: Add `IsRequestAware` method CookieHandler.
Signed-off-by: Mark Laing <mark.laing@canonical.com>
* pkg/http: Use `secureCookieFunc` when checking a cookie (if set).
Signed-off-by: Mark Laing <mark.laing@canonical.com>
* pkg/http: Error on `SetCookie` if cookie handler is request aware.
Signed-off-by: Mark Laing <mark.laing@canonical.com>
* pkg/http: Add method to set request aware cookies.
Signed-off-by: Mark Laing <mark.laing@canonical.com>
* pkg/http: Add function to create a new request aware cookie handler.
Signed-off-by: Mark Laing <mark.laing@canonical.com>
* pkg/client/rp: Update `trySetStateCookie` function signature.
Use `SetRequestAwareCookie` if the cookie handle is request aware.
This function signature can be updated because it is not exported.
Signed-off-by: Mark Laing <mark.laing@canonical.com>
* pkg/client/rp: Add `GenerateAndStoreCodeChallengeWithRequest` function.
It's not possible to add a `http.Request` argument to
`GenerateAndStoreCodeChallenge` as this would be a breaking change.
Instead, add a new function that accepts a request argument and call
`SetRequestAwareCookie` here.
Signed-off-by: Mark Laing <mark.laing@canonical.com>
* pkg/client/rp: Update PKCE logic to pass request if required by cookie handler.
Signed-off-by: Mark Laing <mark.laing@canonical.com>
* pkg/http: Don't set MaxAge if cookie handler is request aware.
The securecookie field can be nil. Expect the caller to set max age on
the securecookie returned by the secureCookieFunc.
Signed-off-by: Mark Laing <mark.laing@canonical.com>
* pkg/client: Add integration tests for request aware cookie handling.
Adds a new type `cookieSpec` which is accepted as an argument to
`RunAuthorizationCodeFlow`. `TestRelyingPartySession` now runs with
`wrapServer` true/false and with two cookie handlers, one static and one
request aware.
The request aware handler extracts encryption keys from a secret using a
salt from a "login_id" cookie.
Signed-off-by: Mark Laing <mark.laing@canonical.com>
---------
Signed-off-by: Mark Laing <mark.laing@canonical.com>
- Introduced CodeResponseType struct to encapsulate response data.
- Added handleFormPostResponse and handleRedirectResponse functions to manage different response modes.
- Created BuildAuthResponseCodeResponsePayload and BuildAuthResponseCallbackURL functions for better modularity in response generation.
Finally the RFC Best Current Practice for OAuth 2.0 Security has been approved.
According to the RFC:
> Authorization servers MUST support PKCE [RFC7636].
>
> If a client sends a valid PKCE code_challenge parameter in the authorization request, the authorization server MUST enforce the correct usage of code_verifier at the token endpoint.
Isn’t it time we strengthen PKCE support a bit more?
This PR updates the logic so that PKCE is always verified, even when the Auth Method is not "none".
* chore: updating go to 1.24
* fixup! chore: updating go to 1.24
* fixup! fixup! chore: updating go to 1.24
* fix device test (drop read error)
* drop older go versions
* drop unrelated formatter changes
---------
Co-authored-by: Iraq Jaber <IraqJaber@gmail.com>
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
* add default signature algorithm
* implements session_state in auth_request.go
* add test
* Update pkg/op/auth_request.go
link to the standard
Co-authored-by: Tim Möhlmann <muhlemmer@gmail.com>
* add check_session_iframe
---------
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
Co-authored-by: Tim Möhlmann <muhlemmer@gmail.com>
