# Which Problems Are Solved
Zitadel never stored or returned the requested `response_mode` in oidc
Auth Requests. This caused the oidc library to fallback to the default
based on the response_type.
# How the Problems Are Solved
- Store the `response_mode` in the Auth request repo
- Store the `response_mode` in the Auth request v2 events
- Return the `resonse_mode` from the Auth Request v1 and v2
`ResponseMode()` methods. (Was hard-coded to an empty string)
# Additional Changes
- Populate the `response_modes_supported` to the oidc Discovery
Configuration. When it was empty, the standard specifies the default of
`query` and `fragment`. However, our oidc library also supports
`form_post` and by this fix, zitadel now also supports this.
# Additional Context
- Closes#6586
- Reported
https://discord.com/channels/927474939156643850/1151508313717084220
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
Introduced with #6909, the authentication check (API client) and the
token verification on the introspection endpoint where parallelized to
improve performance. Only the first error would be considered and
returned (and the second completely ignored).
This could lead to situations where both the client authentication and
token verification failed and the response would result in a 200 OK with
`active: false`.
# How the Problems Are Solved
- The client authentication check error will always be prioritized.
- An error in the token check will no longer terminate the client
authentication check.
# Additional Changes
None.
# Additional Context
- reported in Discord:
https://discord.com/channels/927474939156643850/1242770807105781760
# Which Problems Are Solved
- Swedish speakers cannot use their beautiful native language ;-)
# How the Problems Are Solved
- Contributes Swedish language for Login, Console, common texts and
Emails
# Additional Changes
- none
# Additional Context
- The PR currently provides all translation files according to
https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#contribute-internationalization.
---------
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
Postgres versions < 16 require an alias for subqueries. The query
executed in the new eventstore didn't add this alias.
# How the Problems Are Solved
Added the alias to the subquery
# Which Problems Are Solved
An admin / application might want to be able to reduce the amount of
roles returned in the token, for example if a user is granted to many
organizations or for specific cases where the application want to narrow
down the access for that token to a specific organization or multiple.
This can now be achieved by providing a scope with the id of the
organization, resp. multiple scopes for every organization, which should
be included.
```
urn:zitadel:iam:org:roles🆔{orgID}
```
**Note:** the new scope does not work when Introspection / Userinfo are
set to legacy mode.
# How the Problems Are Solved
The user info query now has two variants:
1. Variant that returns all organization authorization grants if the new
scope wasn't provided for backward compatibility.
2. Variant that filters the organizations based on the IDs passed in one
or more of the above scopes and returns only those authorization grants.
The query is defined as a `text/template` and both variants are rendered
once in package `init()`.
# Additional Changes
- In the integration tests `assertProjectRoleClaims` now also checks the
org IDs in the roles.
# Additional Context
- Closes#7996
# Which Problems Are Solved
Request to the ZITADEL API currently require multi factor authentication
if the user has set up any second factor.
However, the login UI will only prompt the user to check factors that
are allowed by the login policy.
This can lead to situations, where the user has set up a factor (e.g.
some OTP) which was not allowed by the policy, therefore will not have
to verify the factor, the ZITADEL API however will require the check
since the user has set it up.
# How the Problems Are Solved
The requirement for multi factor authentication based on the user's
authentication methods is removed when accessing the ZITADEL APIs.
Those requests will only require MFA in case the login policy does so
because of `requireMFA` or `requireMFAForLocalUsers`.
# Additional Changes
None.
# Additional Context
- a customer reached out to support
- discussed internally
- relates #7822
- backport to 2.53.x
# Which Problems Are Solved
Introduced with #7822 the access token response incorrectly returned the
`state` parameter.
# How the Problems Are Solved
The `state` will only be returned for access token responses in an
implicit_flow.
# Additional Changes
None.
# Additional Context
- relates to #7822
- relates to
https://github.com/zitadel/oidc/issues/446#issuecomment-2144999644
- backport to 2.53.x
---------
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
# Which Problems Are Solved
Access token checks make sure that there have not been any termination
events (user locked, deactivated, signed out, ...) in the meantime. This
events were filtered based on the creation date of the last session
event, which might cause latency issues in the database.
# How the Problems Are Solved
- Changed the query to use `position` instead of `created_at`.
- removed `AwaitOpenTransactions`
# Additional Changes
Added the `position` field to the `ReadModel`.
# Additional Context
- relates to #8088
- part of #7639
- backport to 2.53.x
# Which Problems Are Solved
When an error occurred during the oidc session creation from
client_credentials or jwt_profile, the error was ignored.
# How the Problems Are Solved
Return the error.
# Additional Changes
None.
# Additional Context
- relates to #7822
- noticed internally
- backport to 2.53.x
# Which Problems Are Solved
After migrating the access token events in #7822, milestones based on
authentication, resp. theses events would not be reached.
# How the Problems Are Solved
Additionally use the `oidc_session.Added` event to check for
`milestone.AuthenticationSucceededOnInstance` and
`milestone.AuthenticationSucceededOnApplication`.
# Additional Changes
None.
# Additional Context
- relates to #7822
- noticed internally
# Which Problems Are Solved
The init job fails if no database called *postgres* or *defaultdb* for
cockroach respectively exists.
# How the Problems Are Solved
The value is now configurable, for example by env variable
*ZITADEL_DATABASE_POSTGRES_ADMIN_EXISTINGDATABASE*
# Additional Context
- Closes#5810
# Which Problems Are Solved
We identified some parts in the code, which could panic with a nil
pointer when accessed without auth request.
Additionally, if a GRPC method was called with an unmapped HTTP method,
e.g. POST instead of GET a 501 instead of a 405 was returned.
# How the Problems Are Solved
- Additional checks for existing authRequest
- custom http status code mapper for gateway
# Additional Changes
None.
# Additional Context
- noted internally in OPS
# Which Problems Are Solved
During tests of 2.53.3 we noticed that in cases where the
`idTokenRoleAssertion` was disabled, claims set in the
preAccessTokenTrigger where also set in the id_token.
# How the Problems Are Solved
The userinfo of the id_token now uses a correct copy of their own.
# Additional Changes
None.
# Additional Context
- relates to #7822
- relates to #8046
# Which Problems Are Solved
After deployment of 2.53.x, customers noted that the roles claims where
always present in the tokens even if the corresponding option on the
client (accessTokenRoleAssertion, idTokenRoleAsseriton) was disabled.
Only the project flag (assertRolesOnAuthentication) would be considered.
Further it was noted, that the action on the preAccessTokenCreation
trigger would not be executed.
Additionally, while testing those issues we found out, that the user
information (name, givenname, family name, ...) where always present in
the id_token even if the option (idTokenUserInfo) was not enabled.
# How the Problems Are Solved
- The `getUserinfoOnce` which was used for access and id_tokens is
refactored to `getUserInfo` and no longer only queries the info once
from the database, but still provides a mechanism to be reused for
access and id_token where the corresponding `roleAssertion` and action
`triggerType` can be passed.
- `userInfo` on the other hand now directly makes sure the information
is only queried once from the database. Role claims are asserted every
time and action triggers are executed on every call.
- `userInfo` now also checks if the profile information need to be
returned.
# Additional Changes
None.
# Additional Context
- relates to #7822
- reported by customers
# Which Problems Are Solved
Introspection errors such as invalid audience and errors in the login UI
such as invalid user agents where all logged as severity error.
# How the Problems Are Solved
Log level for both general loggers is changed to `info`.
# Additional Changes
None
# Additional Context
- internal discussion
# Which Problems Are Solved
The session API was designed to be flexible enough for multiple use
cases / login scenarios, where the login could respect the login policy
or not. The session API itself does not have a corresponding policy and
would not check for a required MFA or alike. It therefore also did not
yet respect the lockout policy and would leave it to the login UI to
handle that.
Since the lockout policy is related to the user and not the login
itself, we decided to handle the lockout also on calls of the session
API.
# How the Problems Are Solved
If a lockout policy is set for either password or (T)OTP checks, the
corresponding check on the session API be run against the lockout check.
This means that any failed check, regardless if occurred in the session
API or the current hosted login will be counted against the maximum
allowed checks of that authentication mechanism. TOTP, OTP SMS and OTP
Email are each treated as a separate mechanism.
For implementation:
- The existing lockout check functions were refactored to be usable for
session API calls.
- `SessionCommand` type now returns not only an error, but also
`[]eventstore.Command`
- these will be executed in case of an error
# Additional Changes
None.
# Additional Context
Closes#7967
---------
Co-authored-by: Elio Bischof <elio@zitadel.com>
# Which Problems Are Solved
Adds the possibility to mirror an existing database to a new one.
For that a new command was added `zitadel mirror`. Including it's
subcommands for a more fine grained mirror of the data.
Sub commands:
* `zitadel mirror eventstore`: copies only events and their unique
constraints
* `zitadel mirror system`: mirrors the data of the `system`-schema
* `zitadel mirror projections`: runs all projections
* `zitadel mirror auth`: copies auth requests
* `zitadel mirror verify`: counts the amount of rows in the source and
destination database and prints the diff.
The command requires one of the following flags:
* `--system`: copies all instances of the system
* `--instance <instance-id>`, `--instance <comma separated list of
instance ids>`: copies only the defined instances
The command is save to execute multiple times by adding the
`--replace`-flag. This replaces currently existing data except of the
`events`-table
# Additional Changes
A `--for-mirror`-flag was added to `zitadel setup` to prepare the new
database. The flag skips the creation of the first instances and initial
run of projections.
It is now possible to skip the creation of the first instance during
setup by setting `FirstInstance.Skip` to true in the steps
configuration.
# Additional info
It is currently not possible to merge multiple databases. See
https://github.com/zitadel/zitadel/issues/7964 for more details.
It is currently not possible to use files. See
https://github.com/zitadel/zitadel/issues/7966 for more information.
closes https://github.com/zitadel/zitadel/issues/7586
closes https://github.com/zitadel/zitadel/issues/7486
### 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
- [ ] 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: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
If an IdP intent succeeded with the user was not linked yet, the IdP
link was then added, the following IdP check on the session API would
then fail with `Intent meant for another user (COMMAND-O8xk3w)`.
This issue was introduced with when allowing IdP intents from other
organizations (https://github.com/zitadel/zitadel/pull/7871)
# How the Problems Are Solved
The IdP link is now correctly checked in the session API (using the
user's organization instead of the one from the intent).
# Additional Changes
- Improved the corresponding integration test to cover the exact
bahvior.
- Tests, which had to be updated with newer cases where additionally
changed to use expectEventstore instead of deprecated eventstoreExpect
and the two eventstore mocks of the session_tests.go where combined.
# Additional Context
- Relates to #7871
- This issue was reported by a customer.
- will be back ported to 2.52.x
# Which Problems Are Solved
A customer noted that after upgrade to 2.53.0, users were no longer able
to reset their passwords through the login UI.
This was due to a accidental change in
https://github.com/zitadel/zitadel/pull/7969
# How the Problems Are Solved
The `preferred_login_name` is now correctly read from the database.
# Additional Changes
None.
# Additional Context
relates to #7969
# Which Problems Are Solved
As already mentioned and (partially) fixed in #7992 we discovered,
issues with v2 tokens that where obtained through an IDP, with
passwordless authentication or with password authentication (wihtout any
2FA set up) using the v1 login for zitadel API calls
- (Previous) authentication through an IdP is now correctly treated as
auth method in case of a reauth even when the user is not redirected to
the IdP
- There were some cases where passwordless authentication was
successfully checked but not correctly set as auth method, which denied
access to ZITADEL API
- Users with password and passwordless, but no 2FA set up which
authenticate just wich password can access the ZITADEL API again
Additionally while testing we found out that because of #7969 the login
UI could completely break / block with the following error:
`sql: Scan error on column index 3, name "state": converting NULL to
int32 is unsupported (Internal)`
# How the Problems Are Solved
- IdP checks are treated the same way as other factors and it's ensured
that a succeeded check within the configured timeframe will always
provide the idp auth method
- `MFATypesAllowed` checks for possible passwordless authentication
- As with the v1 login, the token check now only requires MFA if the
policy is set or the user has 2FA set up
- UserAuthMethodsRequirements now always uses the correctly policy to
check for MFA enforcement
- `State` column is handled as nullable and additional events set the
state to active (as before #7969)
# Additional Changes
- Console now also checks for 403 (mfa required) errors (e.g. after
setting up the first 2FA in console) and redirects the user to the login
UI (with the current id_token as id_token_hint)
- Possible duplicates in auth methods / AMRs are removed now as well.
# Additional Context
- Bugs were introduced in #7822 and # and 7969 and only part of a
pre-release.
- partially already fixed with #7992
- Reported internally.
# Which Problems Are Solved
Queriying events by an aggregate id can produce high loads on the
database if the aggregate id contains many events (count > 1000000).
# How the Problems Are Solved
Instead of using the postion and in_tx_order columns we use the sequence
column which guarantees correct ordering in a single aggregate and uses
more optimised indexes.
# Additional Context
Closes https://github.com/zitadel/DevOps/issues/50
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
Potential nil pointers leading to a panic in the login UI.
# How the Problems Are Solved
As of now the login UI did not always check if the authRequest was
actually retrieved form the database, which is ok for some endpoints
which can also be called outside of an auth request.
There are now methods added to ensure the request is loaded.
# Additional Changes
None
# Additional Context
Closes https://github.com/zitadel/DevOps/issues/55
# Which Problems Are Solved
Curretly loading targets fails on cockraochdb because the order of
`with`-statements is wrong.
# How the Problems Are Solved
Changed the order of queries in the statements.
If the feature is enabled the new packages are used to query org by id
Part of: https://github.com/zitadel/zitadel/issues/7639
### 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
- [ ] Critical parts are tested automatically
- [ ] Where possible E2E tests are implemented
- [ ] 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.
# Which Problems Are Solved
Currently on instance setup there is only a possibility to either use a
human or a machine user and not both at creation.
# How the Problems Are Solved
The logic in the instance setup is refactored and changed so there is
not an exclusion.
# Additional Changes
Refactoring, so that unit testing is possible to add for the different
elements of an instance setup.
# Additional Context
Closes#6430
# Which Problems Are Solved
There is confusing ambiguity in the error messages for setting too long
passwords in different places.
# How the Problems Are Solved
A check for maximum password length is added so it's clear that
passwords can't exceed a maximum length of 70 or 72 bytes.
Password validation now provides a live updating check mark or cross
mark to indicate if the maximum length requirement is met.
# Additional Changes
Clarified requirement descriptions on the registration page with
complete sentences.
# Additional Context
Closes#6301
---------
Co-authored-by: Elio Bischof <elio@zitadel.com>
# Which Problems Are Solved
After https://github.com/zitadel/zitadel/pull/7822 was merged we
discovered that
v2 tokens that where obtained through an IDP using the v1 login, can't
be used for
zitadel API calls.
- Because we used to store the AMR claim on the auth request, but
internally use the domain.UserAuthMethod type. AMR has no notion of an
IDP login, so that "factor" was lost
during conversion. Rendering those v2 tokens invalid on the zitadel API.
- A wrong check on machine user tokens falsly allowed some tokens to be
valid
- The client ID was set to tokens from client credentials and JWT
profile, which made client queries fail in the validation middleware.
The middleware expects client ID unset for machine users.
# How the Problems Are Solved
Store the domain.AuthMethods directly in the auth requests and session,
instead of using AMR claims with lossy conversion.
- IDPs have seperate auth method, which is not an AMR claim
- Machine users are treated specialy, eg auth methods are not required.
- Do not set the client ID for client credentials and JWT profile
# Additional Changes
Cleaned up mostly unused `oidc.getInfoFromRequest()`.
# Additional Context
- Bugs were introduced in https://github.com/zitadel/zitadel/pull/7822
and not yet part of a release.
- Reported internally.
# Which Problems Are Solved
ZITADEL currently always uses
`urn:oasis:names:tc:SAML:2.0:nameid-format:persistent` in SAML requests,
relying on the IdP to respect that flag and always return a peristent
nameid in order to be able to map the external user with an existing
user (idp link) in ZITADEL.
In case the IdP however returns a
`urn:oasis:names:tc:SAML:2.0:nameid-format:transient` (transient)
nameid, the attribute will differ between each request and it will not
be possible to match existing users.
# How the Problems Are Solved
This PR adds the following two options on SAML IdP:
- **nameIDFormat**: allows to set the nameid-format used in the SAML
Request
- **transientMappingAttributeName**: allows to set an attribute name,
which will be used instead of the nameid itself in case the returned
nameid-format is transient
# Additional Changes
To reduce impact on current installations, the `idp_templates6_saml`
table is altered with the two added columns by a setup job. New
installations will automatically get the table with the two columns
directly.
All idp unit tests are updated to use `expectEventstore` instead of the
deprecated `eventstoreExpect`.
# Additional Context
Closes#7483Closes#7743
---------
Co-authored-by: peintnermax <max@caos.ch>
Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
Add a check for circular includes in action v2 executions, so that no
self-includes or infinite loops can happen.
Closes#7445
### 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.
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
During the implementation of #7486 it was noticed, that projections in
the `auth` database schema could be blocked.
Investigations suggested, that this is due to the use of
[GORM](https://gorm.io/index.html) and it's inability to use an existing
(sql) transaction.
With the improved / simplified handling (see below) there should also be
a minimal improvement in performance, resp. reduced database update
statements.
# How the Problems Are Solved
The handlers in `auth` are exchanged to proper (sql) statements and gorm
usage is removed for any writing part.
To further improve / simplify the handling of the users, a new
`auth.users3` table is created, where only attributes are handled, which
are not yet available from the `projections.users`,
`projections.login_name` and `projections.user_auth_methods` do not
provide. This reduces the events handled in that specific handler by a
lot.
# Additional Changes
None
# Additional Context
relates to #7486
# Which Problems Are Solved
- In #7929 it was detected that it would be better to show the
activate/deactivate action for a SMTP configuration in the wizard as for
some users it'd not be intuitive that the SMTP provider must be
activated so Zitadel can use it to send notifications.
# How the Problems Are Solved
- When a new SMTP provider is added or updated, the wizard has a new
step that allow us to activate or deactivate the provider configured in
the previous step. The following video shows the new wizard:
https://github.com/zitadel/zitadel/assets/30386061/178234d6-73dc-4719-af0b-1d6f19bf3f7d
# Additional Context
- Closes#7929
# Which Problems Are Solved
The session update requires the current session token as argument.
Since this adds extra complexity but no real additional security and
prevents case like magic links, we want to remove this requirement.
We still require the session token on other resouces / endpoints, e.g.
for finalizing the auth request or on idp intents.
# How the Problems Are Solved
- Removed the session token verifier in the Update Session GRPc call.
- Removed the session token from login UI examples session update calls
# Additional Changes
- none
# Additional Context
- Closes#7883
# Which Problems Are Solved
When poviding `select_account` in an OIDC auth request, ZITADEL would
always show the account selection page even if there aren't any user
sessions to choose and the user would then need to click the `Other
User` button to be presented the login page.
# How the Problems Are Solved
This PR changes the behavior and ignores the `select_account` prompt in
case there aren't any existing user sessions and will directly present
the login page.
# Additional Changes
None
# Additional Context
Closes#7213
* implement code exchange
* port tokenexchange to v2 tokens
* implement refresh token
* implement client credentials
* implement jwt profile
* implement device token
* cleanup unused code
* fix current unit tests
* add user agent unit test
* unit test domain package
* need refresh token as argument
* test commands create oidc session
* test commands device auth
* fix device auth build error
* implicit for oidc session API
* implement authorize callback handler for legacy implicit mode
* upgrade oidc module to working draft
* add missing auth methods and time
* handle all errors in defer
* do not fail auth request on error
the oauth2 Go client automagically retries on any error. If we fail the auth request on the first error, the next attempt will always fail with the Errors.AuthRequest.NoCode, because the auth request state is already set to failed.
The original error is then already lost and the oauth2 library does not return the original error.
Therefore we should not fail the auth request.
Might be worth discussing and perhaps send a bug report to Oauth2?
* fix code flow tests by explicitly setting code exchanged
* fix unit tests in command package
* return allowed scope from client credential client
* add device auth done reducer
* carry nonce thru session into ID token
* fix token exchange integration tests
* allow project role scope prefix in client credentials client
* gci formatting
* do not return refresh token in client credentials and jwt profile
* check org scope
* solve linting issue on authorize callback error
* end session based on v2 session ID
* use preferred language and user agent ID for v2 access tokens
* pin oidc v3.23.2
* add integration test for jwt profile and client credentials with org scopes
* refresh token v1 to v2
* add user token v2 audit event
* add activity trigger
* cleanup and set panics for unused methods
* use the encrypted code for v1 auth request get by code
* add missing event translation
* fix pipeline errors (hopefully)
* fix another test
* revert pointer usage of preferred language
* solve browser info panic in device auth
* remove duplicate entries in AMRToAuthMethodTypes to prevent future `mfa` claim
* revoke v1 refresh token to prevent reuse
* fix terminate oidc session
* always return a new refresh toke in refresh token grant
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
* fix: import totp in add human user with secret
* fix: import totp in add human user with secret
* fix: import totp in add human user with secret
* fix: review comment changes
* fix: correct resourceowner of intent to instance
* fix: correct resourceowner of intent to instance
* fix: correct resourceowner of intent to instance
* fix: correct resourceowner of intent to instance
* fix: correct resourceowner of intent to instance
* docs: expand the login example with org specific parameters
* fix: existence of idp is not checked through resourceowner
* fix: existence of idp is not checked through resourceowner
* fix: existence of idp is not checked through resourceowner
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
