# Which Problems Are Solved
TOTP codes could be reused, violating [RFC 6238, section
5.2](https://datatracker.ietf.org/doc/html/rfc6238#section-5.2).
# How the Problems Are Solved
Transmitted codes are now recorded in each success event. As the codes
amount to secrets, they are not stored verbatim but as a randomly salted
HMAC-SHA256 (`crypto.HMACValue`). Each value gets a fresh random salt,
so an equal code always produces a different stored value and two
entries can never be recognized as being derived from the same code.
This is deliberately not a replacement for proper secret storage: with
the salt stored alongside the hash and a 6 digit payload, anyone with
event access can brute-force the code in milliseconds. That is
acceptable here because a code is worthless once its window has passed.
The `HMACValue` doc comment states the same.
TOTP codes are low-entropy (6 digits), pseudo random codes. Therefore it
is possible for the same code to be generated more than once over the
lifetime of a user. In order to prevent the (unlikely) case where users
login with large time intervalls and a generated code may be equal to
the one last used a long time ago, we only check for codes used within
the recent period window.
A simpler implementation would be simply storing the latest consumed
step, but the TOTP library does not return this value. Because of the
allowed skew there are always 3 steps within the validation window, so
we can't calculate the current step based on time alone. The retained
history spans one period more than the validation window: validity is
decided by the app server's clock, while the stored events carry the
database clock, and the extra period absorbs the drift between them.
**Note:** a reused code pushes a distinct
`user.human.mfa.otp.check.reused` event, not a failed check event. A
replay therefore stays observable through the Events API without
counting towards the lockout policy. Otherwise anyone who captured a
code could replay it to lock the user out.
# Additional Changes
- Read only the latest events in recheck query
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/6452
---------
Co-authored-by: Livio Spring <[email protected]>
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: muhlemmer <[email protected]>
# Which Problems Are Solved
For username/email + password, "login data" seems like uncommon and
confusing terminology to me.
I also think "loginname" is that, maybe it should be written like "login
name" or "username", but I'm having oversight with that now because it
seems to be the way Zitadel calls it.
Here's what Gemini has to say:
> Login Credentials: This is the most widely accepted and formal term in
the tech and security industry. A "credential" is an item of information
that confirms an identity. The pair (username/email and password) is the
set of identifiers used to authenticate the user and grant access (i.e.,
log in).
>
> Login Details: This is also very common in general use and often used
interchangeably with "login credentials," especially in user-facing
contexts (e.g., "Please enter your login details"). It is slightly less
formal than "credentials."
>
> Login Data: While technically correct (as the information is data),
this term is less specific and is more commonly used when referring to a
larger collection of information, like a file containing many users'
credentials, or the data transmitted during the login process.
# How the Problems Are Solved
Renames all occurrences of login data or login credentials to login
details.
# Additional Changes
None.
# Additional Context
I believe this is an improvement but feel free to object.
Co-authored-by: Max Peintner <[email protected]>
Co-authored-by: Ramon <[email protected]>
# Which Problems Are Solved
The following terms have all been renamed to management console:
- Customer Portal (when used to mean the console)
- Console
- Admin Console
# How the Problems Are Solved
- Search & Replace smartly
- Use Copilot for translation files
Changes done to: backend + frontend codebase, docs, translations and
protobufs (descriptions only)
# Additional Context
- Partially Closes#11279
## Which Problems Are Solved
- Add comprehensive Arabic language support to ZITADEL
## How the Problems Are Solved
- Added full Arabic translation files for the login UI, console, and
notification (yaml and json).
- Ensured all keys match the latest English reference files to avoid
missing or inconsistent entries.
- Updated the localization loader to include `ar` as a supported
language.
## Additional Changes
## Additional Context
Closes#11146
---------
Co-authored-by: Marco A. <[email protected]>
# Which Problems Are Solved
Naming inconsistency w.r.t the usage of Given Name / Family Name instead
of First Name / Last Name
# How the Problems Are Solved
* By replacing given and family names with first and last names in UI
and docs (not in the API definitions)
* Updated translations in multiple languages to first and last names
instead of given/family names
# Additional Changes
* Add `internal/**/*.yaml` path to the nx sources input to rebuild the
binary upon changes to these files
* Fix failing unit tests in `user_notifier_legacy_test.go` by updating
`Passwordless` with `Passkey`
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/11308
---------
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Wim Van Laer <[email protected]>
# Which Problems Are Solved
Strings previously were:
- The user must **be member** of the {{.OrgName}} organization.
Fixed the grammar mistake / typo and it's now:
- The user must **be a member** of the {{.OrgName}} organization.
Co-authored-by: Wim Van Laer <[email protected]>
## Summary
- Add comprehensive Ukrainian language support to ZITADEL
- Complete translation of all user-facing interfaces
- Integration with existing language configuration system
## Changes Made
- ✅ **Console translations**: Complete Ukrainian translation for admin
console (2,861 translated strings)
- ✅ **Login interface**: Ukrainian translations for authentication flows
(535 strings)
- ✅ **Email notifications**: Ukrainian translations for system emails
(68 strings)
- ✅ **Common texts**: Ukrainian translations for success/error messages
(1,417 strings)
- ✅ **Language configuration**: Added Ukrainian to supported languages
and Angular locale registration
- ✅ **UI integration**: Added Ukrainian option to language selection
forms
## Translation Quality
- Professional translations using established Ukrainian IT terminology
- Formal language appropriate for business software
- Consistent terminology across all components (Users→Користувачі,
Organization→Організація, etc.)
- Preserved all technical placeholders, HTML tags, and formatting
## Contributing Guidelines Compliance
- ✅ Followed semantic commit message format
- ✅ Added Ukrainian to all required configuration files
- ✅ Maintained consistent file structure with existing languages
- ✅ Used formal Ukrainian appropriate for business software
The Ukrainian translation is now ready for review by the ZITADEL team! 🚀
---------
Co-authored-by: Marco A. <[email protected]>
# Which Problems Are Solved
- Inconsistencies in the terminology used for "身份认证提供商" (identity
provider) and "身份认证提供者" (identity supplier) in the Chinese translation
files could lead to confusion among users.
- Missing translations for terminology related to identity providers
could hinder user experience and understanding.
# How the Problems Are Solved
- Unified the terms "身份认证提供商" and "身份认证提供者" to consistently use
"身份认证提供者" across all Chinese translation files.
- Added necessary translations to ensure that all relevant terms related
to identity providers are accurately represented in the Chinese
localization.
# Additional Changes
- Improved overall readability and clarity in the Chinese translations
by ensuring consistent terminology for identity-related phrases
throughout the application.
- Complete the missing translations.
# Additional Context
If I have missed any translations, please point them out, and I would be
happy to complete them.
---------
Co-authored-by: Florian Forster <[email protected]>
- Turkish language support is added.
- Updated other language files to add Turkish selection.
# Which Problems Are Solved
- Zitadel was not supporting Turkish language. Now supporting.
# How the Problems Are Solved
- Turkish language files are added and updated other language files in
below paths to add Turkish support;
- /console/src/assets/i18n/
- /internal/api/ui/login/static/i18n
- /internal/notification/static/i18n
- /internal/static/i18n
# Additional Changes
- Made changes below files for codes/docs changes;
- /console/src/app/utils/language.ts
- /console/src/app/app.module.ts
- /docs/docs/guides/manage/customize/texts.md
- /internal/api/ui/login/static/templates/external_not_found_option.html
- /internal/query/v2-default.json
- /login/apps/login/src/lib/i18n.ts
---------
Co-authored-by: Marco A. <[email protected]>
# Which Problems Are Solved
- Lack of support for the Romanian language in the application.
# How the Problems Are Solved
- Added translations for the Romanian language
---------
Co-authored-by: Silvan <[email protected]>
# Which Problems Are Solved
The current login will always prefer external authentication (through an
IdP) over local authentication. So as soon as either the user had
connected to an IdP or even when the login policy was just set up to
have an IdP allowed, users would be redirected to that IdP for
(re)authentication.
This could lead to problems, where the IdP was not available or any
other error occurred in the process (such as secret expired for
EntraID).
Even when local authentication (passkeys or password) was allowed for
the corresponding user, they would always be redirected to the IdP
again, preventing any authentication. If admins were affected, they
might not even be able to update the client secret of the IdP.
# How the Problems Are Solved
Errors during the external IdP flow are handled in an
`externalAuthFailed` function, which will check if the organisation
allows local authentication and if the user has set up such.
If either password or passkeys is set up, the corresponding login page
will be presented to the user. As already with local auth passkeys is
preferred over password authentication.
The user is informed that the external login failed and fail back to
local auth as an error on the corresponding page in a focused mode. Any
interaction or after 5 second the focus mode is disabled.
# Additional Changes
None.
# Additional Context
closes#6466
# Which Problems Are Solved
Typo in RU localization on login page.
# How the Problems Are Solved
Fixed typo by replacing to correct text.
# Additional Changes
n/a
# Additional Context
n/a
Co-authored-by: Tim Möhlmann <[email protected]>
Hello everyone,
To support Korean-speaking users who may experience challenges in using
this excellent tool due to language barriers, I have added Korean
language support with the help of ChatGPT.
I hope that this contribution allows ZITADEL to be more useful and
accessible to Korean-speaking users.
Thank you.
---
안녕하세요 여러분, 언어의 어려움으로 이 훌륭한 도구를 활용하는데 곤란함을 겪는 한국어 사용자들을 위하여 ChatGPT의 도움을
받아 한국어 지원을 추가하였습니다.
이 기여를 통해 ZITADEL이 한국어 사용자들에게 유용하게 활용되었으면 좋겠습니다.
감사합니다.
Co-authored-by: Max Peintner <[email protected]>
# Which Problems Are Solved
- The quality of the Russian locale in the auth module is currently low,
likely due to automatic translation.
# How the Problems Are Solved
- Corrected grammatical errors and awkward phrasing from
auto-translation (e.g., "footer" → ~"нижний колонтитул"~ "примечание").
- Enhanced alignment with the English (reference) locale, including
improvements to casing and semantics.
- Ensured consistency in terminology (e.g., the "next"/"cancel" buttons
are now consistently translated as "продолжить"/"отмена").
- Improved clarity and readability (e.g., "подтверждение пароля" →
"повторите пароль").
# Additional Changes
N/A
# Additional Context
- Follow-up for PR #6864
Co-authored-by: Fabi <[email protected]>
- Fully translated all UI elements, documentation, and error messages
- Added Hungarian as a new supported language option
- Updated language selection menus and related configuration files
- Ensured consistency across all translated content
# Which Problems Are Solved
- ZITADEL was not accessible for Hungarian-speaking users due to lack of
language support
- Hungarian users had to rely on English or other languages to use the
platform
- Potential user base was limited due to language barrier
# How the Problems Are Solved
- Translated all user interface elements, including console and login
interfaces
- Translated all documentation files to Hungarian
- Added Hungarian translations for all error messages and notifications
- Implemented Hungarian as a selectable language option in the system
# Additional Changes
- Updated language selection menus to include Hungarian
- Modified configuration files to support Hungarian language
- Ensured consistent terminology and style across all translated content
- Added Hungarian language option to relevant dropdown menus and
settings
# Additional Context
- Relates to the ongoing internationalization efforts of ZITADEL
- Enhances accessibility for Hungarian-speaking developers and users
- Expands ZITADEL's potential user base in Hungary and
Hungarian-speaking regions
---------
Co-authored-by: Max Peintner <[email protected]>
Co-authored-by: Tim Möhlmann <[email protected]>
Co-authored-by: Stefan Benz <[email protected]>
# Which Problems Are Solved
As an administrator I want to be able to invite users to my application
with the API V2, some user data I will already prefil, the user should
add the authentication method themself (password, passkey, sso).
# How the Problems Are Solved
- A user can now be created with a email explicitly set to false.
- If a user has no verified email and no authentication method, an
`InviteCode` can be created through the User V2 API.
- the code can be returned or sent through email
- additionally `URLTemplate` and an `ApplicatioName` can provided for
the email
- The code can be resent and verified through the User V2 API
- The V1 login allows users to verify and resend the code and set a
password (analog user initialization)
- The message text for the user invitation can be customized
# Additional Changes
- `verifyUserPasskeyCode` directly uses `crypto.VerifyCode` (instead of
`verifyEncryptedCode`)
- `verifyEncryptedCode` is removed (unnecessarily queried for the code
generator)
# Additional Context
- closes#8310
- TODO: login V2 will have to implement invite flow:
https://github.com/zitadel/typescript/issues/166
# Which Problems Are Solved
As of now, **automatic creation** and **automatic linking options** were
only considered if the corresponding **allowed option** (account
creation / linking allowed) was enabled.
With this PR, this is no longer needed and allows administrators to
address cases, where only an **automatic creation** is allowed, but
users themselves should not be allowed to **manually** create new
accounts using an identity provider or edit the information during the
process.
Also, allowing users to only link to the proposed existing account is
now possible with an enabled **automatic linking option**, while
disabling **account linking allowed**.
# How the Problems Are Solved
- Check for **automatic** options without the corresponding **allowed**
option.
- added technical advisory to notify about the possible behavior change
# Additional Changes
- display the error message on the IdP linking step in the login UI (in
case there is one)
- display an error in case no option is possible
- exchanged deprecated `eventstoreExpect` with `expectEventstore` in
touched test files
# Additional Context
closes https://github.com/zitadel/zitadel/issues/7393
---------
Co-authored-by: Stefan Benz <[email protected]>
# Which Problems Are Solved
- Corrected a typo in the file
`internal/api/ui/login/static/i18n/zh.yaml` where "Migrosoft" was
changed to "Microsoft".
# How the Problems Are Solved
- Updated the misspelled word "Migrosoft" to "Microsoft" for consistency
and accuracy.
# Additional Changes
- None
# Additional Context
- None
# Which Problems Are Solved
I fixed spelling, grammar and translation misstakes in the german
translation file.
I noticed something else. Some strings use the formal form ("sie") of
address and some strings use the informal (du) form of address.
# Additional Context
- Discussion #8211
# Which Problems Are Solved
Some organizations / customers have the requirement, that there users
regularly need to change their password.
ZITADEL already had the possibility to manage a `password age policy` (
thought the API) with the maximum amount of days a password should be
valid, resp. days after with the user should be warned of the upcoming
expiration.
The policy could not be managed though the Console UI and was not
checked in the Login UI.
# How the Problems Are Solved
- The policy can be managed in the Console UI's settings sections on an
instance and organization level.
- During an authentication in the Login UI, if a policy is set with an
expiry (>0) and the user's last password change exceeds the amount of
days set, the user will be prompted to change their password.
- The prompt message of the Login UI can be customized in the Custom
Login Texts though the Console and API on the instance and each
organization.
- The information when the user last changed their password is returned
in the Auth, Management and User V2 API.
- The policy can be retrieved in the settings service as `password
expiry settings`.
# Additional Changes
None.
# Additional Context
- closes#8081
---------
Co-authored-by: Tim Möhlmann <[email protected]>
# 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 <[email protected]>
Co-authored-by: Livio Spring <[email protected]>
# 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 <[email protected]>
* init auto linking
* prompt handling
* working
* translations
* console
* fixes
* unify
* custom texts
* fix tests
* linting
* fix check of existing user
* fix bg translation
* set unspecified as default in the form
feat: updated russian translations by native speaker with a user polite approach
Co-authored-by: Pavel Girilyuk <[email protected]>
Co-authored-by: Fabi <[email protected]>
* feat: replace inactive remove active from select account
* fix: apply same behavior to console user select
---------
Co-authored-by: Livio Spring <[email protected]>
* add macedonian language to currently supported languages
* mk yaml login static with en values
* mk json assets with en values
* mk yaml notification static with en values
* add macedonian notification yaml
* mk yaml static with en values
* mk translations for login
* mk translations for internal
* macedonian translations
* - fix lint issues
Marco A.andGitHub
Kenta YamaguchiandGitHub
FabiandGitHub
Zhang ZheandGitHub
RedstonePfalzandGitHub
petrmifekandGitHub
some-user123andGitHub
Vlatko StojkovskiandGitHub
