# Which Problems Are Solved
Add pnpm overrides to resolve two security vulnerabilities in transitive
dependencies:
node-tar (CVE-2026-23745): Arbitrary file overwrite and symlink
poisoning via insufficient path sanitization — fixed by overriding to
>=7.5.3
Rollup 4 (#477): Arbitrary file write via path traversal — fixed by
overriding to >=4.59.0
# How the Problems Are Solved
applied overrides in package.json
# Which Problems Are Solved
Updated the project to use the latest versions of Next.js and React, and
implemented a SWR caching strategy for key settings API calls to improve
performance. Adjusted configuration to ensure compatibility with Next.js
16.
# How the Problems Are Solved
- Updated next to 16.1.6, react & react-dom to 19.2.4, and next-intl to
4.8.3.
- Implemented `API_CACHE_ENABLED` and `API_CACHE_CONFIG` (replacing
deprecated unstable_cacheLife) for:
- getBrandingSettings
- getSecuritySettings
- getPasswordComplexitySettings
- getLoginSettings ...
- Updated default theme colors from blue to a more neutral black and
white
# Additional changes
- Updated login docker image to node 24
---------
Co-authored-by: Ramon <[email protected]>
# Which Problems Are Solved
Removes the Cypress integration tests and associated configuration from
the apps/login project to streamline the build process.
# How the Problems Are Solved
- Removed cypress directory, integration directory, and
cypress.config.ts from apps/login.
- Updated project.json to remove test-integration targets and
dependencies.
- Updated package.json to remove the cypress dev dependency and clean
script reference.
- Updated tsconfig.json to remove the now-redundant integration
exclusion.
- Ensured acceptance tests are preserved and correctly excluded from
build inputs.
---------
Co-authored-by: Florian Forster <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: conblem <[email protected]>
Closes#11096
# Which Problems Are Solved
This pull request resolves a 404 error that occurred at the end of the
LDAP login flow.
Previously, when a user submitted their LDAP credentials in the
apps/login application, the form initiated the session creation process
but incorrectly redirected the user to /idp/ldap/success, a route that
does not exist. In addition, the redirect failed to preserve necessary
IDP context parameters (such as requestId, organization, and linking
fingerprint info) that are required to fully complete the authentication
intent.
# How the Problems Are Solved
- Fixed redirect path: Updated `createNewSessionForLDAP` to redirect to
`/idp/ldap/process` instead of success, aligning it with the standard
IDP intent processing pipeline which dynamically resolves
`[provider]/process`.
- Preserved context parameters: Extracted `requestId`, `organization`,
`postErrorRedirectUrl`, `linkToSessionId`, and `linkFingerprint` from
the URL parameters on the LDAP page and passed them through
LDAPUsernamePasswordForm down to the server action so the ongoing auth
request is successfully tied to the user's intent.
Closes#11138
# Which Problems Are Solved
Previously, the application strictly checked the allowRegister
setting—which typically applies to local account creation—before
considering if a user without an account should be redirected to an IDP,
or whether they could access the register page. This blocked users from
registering via identity providers when local registration was disabled
but IDPs were configured.
# How the Problems Are Solved
- Removed the allowRegister dependency when deciding to redirect an
unknown user to an IDP. The logic now only checks
!allowLocalAuthentication, correctly opening up the IDP registration
flow even when local auth/registration is not allowed.
- Modified the block condition so the register page is only restricted
if allowRegister is false and there are no configured identityProviders
available.
# Which Problems Are Solved
- Currently, if a user has only secondary authentication methods (like
TOTP) configured but no primary authentication method (Password,
Passkey, or IDP), the login flow fails to handle them correctly,
resulting in an unhelpful "user not found" error when they attempt to
log in.
- These users are not correctly prompted to set up a primary
authentication factor, leaving them in a state where they cannot
successfully authenticate.
# How the Problems Are Solved
- Updated `sendLoginname` to evaluate if a user has an active primary
authentication method (`AuthenticationMethodType.PASSWORD`, `PASSKEY`,
or `IDP`. If they lack a primary method, the flow now correctly
redirects them into the verification/invite process rather than falling
through the method checks and returning a generic error.
- Updated `sendVerification` to replace the empty `authMethodTypes`
array check with a specific check for primary authentication methods.
Now, after completing email/invite verification, users who do not have a
primary authentication method are explicitly redirected to
`/authenticator/set` to set one up.
Closes#11199
# Which Problems Are Solved
This PR refactors the login app to load allowed languages and the
default language directly from the Zitadel API equivalents
(`getGeneralSettings`), rather than relying on a hardcoded list. This
ensures that the available languages in the UI and the locale selection
logic match the instance's configuration.
# How the Problems Are Solved
- Fetches allowed languages server-side and passes them to the
LanguageSwitcher
- The NEXT_LOCALE cookie and Accept-Language headers are now strictly
validated against the API-provided allowed languages.
- Fallback: If a cookie requests an unsupported language, the system now
falls back to the API's defaultLanguage (instead of valid but
unconfigured defaults).
# Additional Changes
Helper: Added `getLanguage(code)` to map API language codes to display
names (utilizing Intl.DisplayNames if the code isn't in our static
mapping).
---------
Co-authored-by: Livio Spring <[email protected]>
# Which Problems Are Solved
This PR introduces robust redirect configuration options and enhances
security for Server Actions in multi-domain setups.
# How the Problems Are Solved
- Redirect Fallback Logic: Implemented a unified `resolveRedirectUri`
utility that prioritizes redirect targets as follows:
- Environment override (`DEFAULT_REDIRECT_URI`)
- Organization settings (`defaultRedirectUri`).
- Relative fallback (`/signedin?...`).
- Host Reflection: `DEFAULT_REDIRECT_URI` supports absolute URLs or
relative paths via host reflection.
- Server Action Security: Configured `serverActions.allowedOrigins` to
be dynamically manageable via the `SERVER_ACTION_ALLOWED_ORIGINS`
environment variable (comma-separated list). It defaults to an empty
list for maximum security.
- UI Integration: Updated the /signedin page to use the unified redirect
logic, ensuring consistent behavior for the "Continue" button.
- Documentation: Added type definitions and detailed descriptions for
new environment variables in
`next-env-vars.d.ts`
---------
Co-authored-by: Copilot <[email protected]>
Closes#10816Closes#10759
# Which Problems Are Solved
This PR refactors the SAML Post binding flow to address issues with
payloads exceeding browser cookie size limits (typically ~4KB).
Previously, the SAML form data was serialized into a cookie, and the
user was redirected to an intermediate /saml-post page to render the
form. This approach failed for large SAML assertions.
# How the Problems Are Solved
The new implementation bypasses cookies entirely for the payload
transfer. Server actions now return the form data directly to the
client, which immediately renders and submits the form.
- Direct Data Transfer: Updated `startIdentityProviderFlow` to return an
object { url, fields } instead of a redirect URL when the next step is
formData.
- Server Actions: Updated redirectToIdp, sendLoginname, and
completeAuthFlow to propagate this samlData object to the client.
- Client-Side Auto-Submission: Added a new AutoSubmitForm component that
renders a hidden form with the provided fields and automatically submits
it to the IdP on mount.
---------
Co-authored-by: conblem <[email protected]>
# Which Problems Are Solved
This PR deprecates and replaces the use of `allowUsernamePassword` with
`allowLocalAuthentication`.
It additionally disables the username on organizations that disallow
local authentication. In such a case, only IDPs are shown.
# How the Problems Are Solved
- replace `allowUsernamePassword` by `allowLocalAuthentication`
- disable username form if !allowLocalAuthentication
- translate property in console UI
Closes#11386
# Which Problems Are Solved
This PR fixes an issue where the `successUrl` and `failureUrl` for
implicit IdP flows (initiated via OIDC `idp🆔...` scopes) were being
constructed using `request.nextUrl.origin`. This failed to account for:
- `x-zitadel-forward-host` headers (essential for proper public URL
resolution).
- `NEXT_PUBLIC_BASE_PATH` configuration.
# How the Problems Are Solved
The fix replaces the manual string concatenation with the shared
`constructUrl` helper, ensuring consistent and correct URL generation.
Co-authored-by: Livio Spring <[email protected]>
Closes#11345
# Which Problems Are Solved
When changing password, users could have run into a race condition /
eventual consistency issue which resulted in:
- Verification failures in `sendPassword`
- The user receiving a `couldNotCreateSession` or
`couldNotCreateSessionForUser` error despite providing a valid password.
# How the Problems Are Solved
- Previously, `checkSessionAndSetPassword` was fired without await,
causing the code to proceed immediately to
`sendPassword`. This resulted in `sendPassword` trying to verify the
user's session with the new password before the password update had
actually completed on the server.
- Now the password change call is executed by the login service user
only, ommitting eventual `membership not found (AUTHZ-cdgFk)` errors
from the API by using the user session itself. The login checks for a
recent password change (within 5 minutes) as well to ensure session
freshness.
# Which Problems Are Solved
This PR fixes a problem where expired or cleared sessions could not be
reauthenticated when passkey was set as single method.
# How the Problems Are Solved
The logic now correctly falls back to creating a new session if the
context is provided.
Co-authored-by: Livio Spring <[email protected]>
Closes#11006
# Which Problems Are Solved
This PR addresses an issue where the ignoreUnknownUsernames setting was
not being respected in certain scenarios during the login flow.
Specifically:
- When a user was found but rejected due to login settings (e.g.,
disableLoginWithEmail), the system would return a "User not found" error
instead of redirecting to the password page as dictated by
ignoreUnknownUsernames.
- When a user was not found, and the flow fell through the registration
checks (e.g., IDP redirect failed), it would also return "User not
found" without checking ignoreUnknownUsernames.
# How the Problems Are Solved
- Introduced a helper function `handleUserNotFound` in
`apps/login/src/lib/server/loginname.ts` to centralize the logic for
checking ignoreUnknownUsernames and redirecting to the password page.
- Updated the user validation logic to call handleUserNotFound when a
user is found but rejected by policy.
- Updated the registration fallback logic to call handleUserNotFound
instead of directly returning an error.
- Added new test cases in `apps/login/src/lib/server/loginname.test.ts`
to verify the fix and ensure no regressions.
# Additional Changes
- Fixed inconsistency in translation files
---------
Co-authored-by: Livio Spring <[email protected]>
# Which Problems Are Solved
Fixes a problem where submit buttons where not correctly enabled onBlur
event
# How the Problems Are Solved
By changing the react-hook-form mode property to onChange, buttons are
enabled as intended
Closes#11184
# Which Problems Are Solved
- loginName: This information is already retrievable from the URL
parameters during the authentication flow, so logging it presented no
additional exposure.
- idpIntent: This was being logged to the server console (server-side
logs), so it was never exposed to the client/browser.
These changes simply clean up the server logs to prevent unnecessary
data noise.
# How the Problems Are Solved
- Removed idpIntent logging from
`apps/login/src/lib/server/idp-intent.ts`
- Removed loginName logging from
`apps/login/src/lib/server/password.ts`
---------
Co-authored-by: Livio Spring <[email protected]>
# Which Problems Are Solved
The application automatically appends the x-zitadel-public-host header
when a public host is configured. In some deployment scenarios where the
host is determined by default or via other means, sending this header
allows for improper routing or is simply redundant. The existing
CUSTOM_REQUEST_HEADERS configuration only supported adding or
overwriting headers, offering no way to remove headers that were set by
default logic.
# How the Problems Are Solved
Extended the `CUSTOM_REQUEST_HEADERS` handling in `src/lib/zitadel.ts`.
The logic now checks for empty header values. If a header is defined in
`CUSTOM_REQUEST_HEADERS` with an empty value (e.g.,
x-zitadel-public-host:), the interceptor will delete that header from
the request instead of setting it to an empty string. This allows users
to opt-out of default headers via configuration.
Closes#11191
# Which Problems Are Solved
This PR fixes the IDP linking for accounts with no authentication
method.
We strictly validate session ownership and generate a hash of the
sessionId + the user's fingerprintId cookie. This hash is passed to the
IDP as linkFingerprint.
This PR addtionally addresses TypeScript errors regarding unknown types
in catch blocks within the IDP intent processing logic. It ensures that
errors occurring during IDP linking are safely handled, and that
meaningful error messages are propagated to the client-side redirect
URLs.
# How the Problems Are Solved
- Safely handle unknown errors: Updated catch blocks in
`processIDPCallback` to check if the caught object is an instance of
Error before accessing error.message.
- Fix "IDP Taken" check: Implemented a safe check for the gRPC error
code 6 (Already Exists) by casting the error, resolving the Property
'code' does not exist on type 'unknown' build error.
- Error Propagation: The specific error message is now passed to the
linking-failed page params, allowing for better user feedback instead of
generic errors.
Closes#11192
# Which Problems Are Solved
Update pnpm, react and react-dom to the latest version
# How the Problems Are Solved
the version references are updated as part of the package.json files
# Which Problems Are Solved
Updates `next` to version `15.5.9` to address the following security
vulnerabilities:
- **CVE-2025-55184**
- **CVE-2025-55183**
# How the Problems Are Solved
- Bump `next` from `15.5.7` to `15.5.9` in `apps/login/package.json`
---------
Co-authored-by: PhenixH <[email protected]>
# Which Problems Are Solved
When users accessed the login page without an organization context and
entered a login name with a domain suffix (e.g., [[email protected]], the
system would return "user not found" instead of performing organization
discovery.
# How the Problems Are Solved
Added organization discovery logic that triggers after a global user
search returns no results. When no organization context is provided:
- Extracts the domain suffix from the loginName (e.g., @company.com)
- Queries for organizations with that domain as their primary domain
- If exactly one organization is found with allowDomainDiscovery
enabled, uses it as the discovered organization
- Redirects users to the appropriate flow (IDP, registration, or
password) with the discovered organization context
---------
Co-authored-by: Ramon <[email protected]>
# Which Problems Are Solved
When users authenticate via IDP (Identity Provider) without explicit
organization context, the flow could fail or create users without proper
organization assignment. This occurred when:
- No organization parameter was provided in the IDP callback
- Domain discovery didn't find a matching organization
- OIDC requests didn't include organization scopes
# How the Problems Are Solved
Implemented a fallback mechanism that ensures organization context is
always available:
- Centralized organization resolution in `resolveOrganizationForUser()`
- First: Use explicitly provided organization
- Second: Attempt domain discovery from username
- Third: Fallback to default organization (NEW)
- Explicit error handling: Users are never created without organization
context. If no organization can be determined (including no default
org), the flow fails gracefully with a clear error message.
- Applied to both creation flows:
- CASE 4: Auto-creation of users
- CASE 5: Manual user registration
Co-authored-by: Ramon <[email protected]>
# Which Problems Are Solved
An IDP Intent could not be completed due to a missing change of
successUrl property in a recent PR.
# How the Problems Are Solved
The /success page has been replaced by /process to finish the IDP flow
in all occurences.
# Which Problems Are Solved
The passkey login page was not rendering properly in production (Cloud
Run) deployments, with the submit button and component content not
appearing. Additionally, the automatic passkey prompt was not triggering
correctly.
# How the Problems Are Solved
Added the missing return statement before navigator.credentials.get() in
the submitLoginAndContinue function. This ensures the promise is
properly returned and chained in the useEffect hook, fixing the
automatic passkey prompt flow.
Removes the recently introduces guides to passkeys that could result in
a hydration error due to the <a> tag being rendered differently on
server / client environement
# Additional Changes
This issue was most probably introduced in PR #10971. The component uses
promise chaining (.then().catch().finally()) which requires the promise
to be returned, unlike the RegisterPasskey component which uses
async/await and works correctly without an explicit return.
# Which Problems Are Solved
This PR enhances the passkey authentication flow with comprehensive
error handling, full internationalization support, and extensive test
coverage.
# How the Problems Are Solved
I18n:
- Replaced all hard-coded error messages with i18n translation keys
- Consistent error messaging throughout the passkey flow
- Added specific error handling for passkey cancellation
(NotAllowedError)
- Implemented fallback errors for undefined/missing responses
- Better error messages for:
- Session retrieval failures
- Challenge request failures
- User verification errors
- Redirect determination issues
Tests:
- Added `login-passkey.test.tsx` with 100+ test cases covering:
- Successful verification flows
- Error scenarios and edge cases
- Props handling
- Component lifecycle
- Added passkeys.test.ts with server-side function tests:
- Session cookie retrieval
- User validation
- Custom lifetime handling
- Critical fallback error paths
Try-catch blocks around critical user retrieval operations
Defensive checks for undefined responses from completeFlowOrGetUrl
Support for custom lifetime parameters
Cleaner error propagation
Closes#10828
# Which Problems Are Solved
The IDP callback flow was calling retrieveIDPIntent() twice, causing
single-use token failures with error: "Intent Token is invalid". This
occurred due to Next.js 15's dynamicIO feature triggering double renders
# How the Problems Are Solved
Completely refactored the IDP callback architecture to ensure single-use
tokens are consumed exactly once:
- Centralized Business Logic: Moved all IDP callback logic into a single
server action (processIDPCallback) that:
- Consumes the token once
- Handles all 6 business scenarios (login, linking, auto-linking,
auto-creation, manual registration, account not found)
- Integrates session creation in the same action
- Returns `{ redirect?: string; error?: string }` for client-side
navigation
- Client Component Invocation: Created `IdpProcessHandler` client
component that:
- Calls the server action from browser context (enables cookie
modification)
- Prevents double execution with useRef
- Handles loading states and error display
- Clean Architecture:
- Removed 403-line success page with complex logic
- Removed component files from `/components/idps/pages/` folder
- Moved all UI directly into server pages
- Created dedicated result pages with minimal params
# Additional Changes
- Added translations to all 8 supported languages
---------
Co-authored-by: Ramon <[email protected]>
# Which Problems Are Solved
When the passkey registration page (/passkey/set) is accessed externally
with only a loginName parameter, users encounter a "Missing code in
response" error. This occurs because the registration code is only
generated for invalid sessions, but external calls typically have valid
sessions.
# How the Problems Are Solved
- Moved registration code generation outside the session validity check
in `registerPasskeyLink()`
- Code is now generated for both valid and invalid sessions when not
provided
- Simplified logic: use provided code if available, otherwise generate a
new one
# Which Problems Are Solved
When a user with no authentication methods attempted to log in, the
system always set `invite=true` in the verification flow, regardless of
whether their email was already verified. This could cause errors when
trying to send invite codes to already initialized users.
# How the Problems Are Solved
Added conditional logic to determine whether to send an invite code
based on the user's email verification status:
This prevents errors when attempting to send invite codes to users who
have already verified their email and been initialized, while still
properly handling new users who need invitation flows.
Closes#10671
# Which Problems Are Solved
Users with password authentication disabled in their organization were
seeing "Username Password not allowed!" error instead of being
redirected to their organization's configured Identity Provider. This
affected domain discovery and multi-tenancy use cases in Login V2.
# How the Problems Are Solved
- Updated `redirectUserToIDP` to accept optional `userId` and
`organization` parameters
- Added fallback logic to check organization-level IDPs via
`getActiveIdentityProviders`
- Updated all call sites to pass appropriate organization context
- Added test coverage for the fallback behavior
# Additional Changes
- Consolidated duplicate logic by removing
`redirectUserToSingleIDPIfAvailable` function, which is now handled by
the unified `redirectUserToIDP` function
- improved error handling on verification page
---------
Co-authored-by: Ramon <[email protected]>
This PR fixes an issue in the IDP auto-linking feature where user
searches were performed globally instead of being scoped to the current
organization context. This could result in IDP links being created for
users in unintended organizations.
# Which Problems Are Solved
When IDP auto-linking was enabled (by email or username), the system
would search for existing users across all organizations instead of
restricting the search to the current organization context.
# How the Problems Are Solved
Added organization scoping to all three auto-linking code paths
# Which Problems Are Solved
Improves the user experience when IDP authentication succeeds but user
creation/linking fails by introducing a `postErrorRedirectUrl` parameter
and dedicated error pages instead of generic error screens.
<img width="580" height="636" alt="Screenshot 2025-10-16 at 09 21 07"
src="https://github.com/user-attachments/assets/db653c8f-b648-4cfe-922a-2f237f3b70b3"
/>
# How the Problems Are Solved
## New Pages
- **`/idp/[provider]/account-not-found`**: Displayed when no user
account exists and creation/linking is not allowed
- **`/idp/[provider]/registration-failed`**: Displayed when user
registration fails due to organization resolution issues
## Flow Improvements
- Added `postErrorRedirectUrl` parameter to track where the IDP flow was
initiated
- Each entry point (loginname, register, idp, authenticator/set)
specifies its own redirect URL
- Users are now redirected to appropriate error pages with clear
messaging instead of generic error screens
- All context (`requestId`, `organization`, `postErrorRedirectUrl`) is
preserved throughout the flow
## Updated Components
- `SignInWithIdp`: Now accepts and passes `postErrorRedirectUrl`
parameter
- `redirectToIdp` server action: Extracts and forwards
`postErrorRedirectUrl` through the IDP flow
- IDP success page: Routes to appropriate error pages based on failure
reason
## i18n
Added new translation keys:
- `idp.accountNotFound.*` - For missing account scenarios
- `idp.registrationFailed.*` - For organization resolution failures
# Which Problems Are Solved
This change shows the default titles for password pages instead of
dynamically showing the user name.
# How the Problems Are Solved
Both pages now show only the translated title text (verify.title and
change.title respectively) instead of falling back to showing the user's
display name.
Co-authored-by: Livio Spring <[email protected]>
# Which Problems Are Solved
This PR introduces a comprehensive theme customization system for the
login application with responsive behavior and enhanced visual options.
<img width="1122" height="578" alt="Screenshot 2025-08-19 at 09 55 24"
src="https://github.com/user-attachments/assets/cdcc8948-533d-4e13-bf45-fdcc24acfb2b"
/>
# How the Problems Are Solved
## ✨ Features Added
- **🔄 Responsive Layout System**: Automatic switching between
side-by-side and top-to-bottom layouts based on screen size
- **🖼️ Background Image Support**: Custom background images configurable
via environment variables
- **⚙️ Theme Configuration**: Complete theme system with roundness,
spacing, appearance, and layout options
- **📱 Mobile-First Design**: Intelligent layout adaptation for different
screen sizes
- **🎯 Enhanced Typography**: Improved visual hierarchy with larger
titles in side-by-side mode
## 🏗️ Architecture
- **Server-Safe Theme Functions**: Theme configuration accessible on
both server and client
- **SSR-Safe Hooks**: Proper hydration handling for responsive layouts
- **Component Separation**: Clear boundaries between server and client
components
- **Two-Section Layout**: Consistent content structure across all login
pages
## 🔧 Configuration Options
All theme options are configurable via environment variables:
- `NEXT_PUBLIC_THEME_ROUNDNESS`: `edgy` | `mid` | `full`
- `NEXT_PUBLIC_THEME_LAYOUT`: `side-by-side` | `top-to-bottom`
- `NEXT_PUBLIC_THEME_APPEARANCE`: `flat` | `material`
- `NEXT_PUBLIC_THEME_SPACING`: `regular` | `compact`
- `NEXT_PUBLIC_THEME_BACKGROUND_IMAGE`: Custom background image URL
## 📄 Pages Updated
Updated all major login pages to use the new two-section responsive
layout:
- Login name entry
- Password verification
- MFA verification
- User registration
- Account selection
- Device authorization
- Logout confirmation
## 📚 Documentation
- **THEME_ARCHITECTURE.md**: Complete technical documentation of the
theme system
- **THEME_CUSTOMIZATION.md**: User-friendly guide with examples and
troubleshooting
## 🚀 Benefits
- **Better UX**: Responsive design that works seamlessly across all
devices
- **Brand Flexibility**: Easy customization to match any brand identity
- **Maintainable Code**: Clean separation of concerns and
well-documented architecture
- **Future-Proof**: Extensible system for additional theme options
<img width="580" height="680" alt="Screenshot 2025-08-19 at 09 22 23"
src="https://github.com/user-attachments/assets/9de8da37-6d56-4fe9-b337-5d8ad2a3ba59"
/>
<img width="599" height="689" alt="Screenshot 2025-08-19 at 09 23 45"
src="https://github.com/user-attachments/assets/26a30cc7-4017-4f4b-8b87-a49466c42b94"
/>
<img width="595" height="681" alt="Screenshot 2025-08-19 at 09 23 17"
src="https://github.com/user-attachments/assets/a3d31088-4545-4f36-aafe-1aae1253d677"
/>
# Which Problems Are Solved
Replace this example text with a concise list of problems that this PR
solves.
For example:
- password complexity requirements have hardcoded English text
- password, loginname, register and verify components have hardcoded
Engilsh error messages/alerts
# How the Problems Are Solved
Replace this example text with a concise list of changes that this PR
introduces.
For example:
- adds i18n for password complexity requirements
- adds i18n for password, loginname, register and verify components
error messages/alerts
# Additional Changes
- small change in code/styles for icons in PasswordComplexity to make
sure that icons keep size
# Additional Context
N.A
---------
Co-authored-by: Adam Kida <[email protected]>
Cleanup redundant script from documentation
# Which Problems Are Solved
We have removed a redundant script
# How the Problems Are Solved
removed the duplicate script from docusaurus.config.js
This changes the source of a script to an internal url to prevent CSP
errors.
# Which Problems Are Solved
Our documentation feedback script was not loaded due to being blocked by
the CSP
# How the Problems Are Solved
By internally routing to a proxy, we do not have to add external urls to
the CSP
Closes#10671
# Which Problems Are Solved
Users with only password authentication method were immediately shown an
error "Username Password not allowed" when
`loginSettings.allowUsernamePassword` was set to false. However, the IDP
flow could potentially allow the user to register a new account or link
an existing account, providing a better user experience than a dead-end
error.
# How the Problems Are Solved
- Modified single password method case to attempt IDP redirect before
showing error
- This allows users to potentially register or link accounts through the
IDP flow instead of hitting an immediate error
- Only show error as last resort when no IDP alternative is available
Closes#10727Closes#10577
# Which Problems Are Solved
This PR fixes the organization domain scope when provided and introduces
a deep-link feature for external applications, that sends users directly
into passkey registration flow using either session-based or sessionless
flows. Previously, the `/passkey/set` page only supported session-based
registration, limiting external application integration scenarios.
The `/passkey/set` page now supports:
- `code` search parameter for automatic passkey registration
- `userId` parameter for sessionless flows (similar to `/verify` and
`/password/set` pages)
- Auto-submit functionality when verification codes are provided
# How the Problems Are Solved
The organization scope is fixed by the backend handler for OIDC flows,
now correctly submitting a `suffix` queryparam to the /loginname url
which is used to show in the input field.
The passkey code support is implemented by support multiple integration
patterns:
- **Session-based**: `/passkey/set?sessionId=123&code=abc123` (existing
flow)
- **Sessionless**: `/passkey/set?userId=123456&code=abc123` (new flow)
External Application Integration Flow
1. External app triggers passkey register and obtains code
2. User verification link containing `userId`, `code` and `id`
parameters
3. User clicks link → `/passkey/set?userId=123&code=abc&id=123`
4. Page loads user information using `userId` parameter
5. Auto-submit triggers passkey registration when `code` and `id` is
present
6. User completes WebAuthn request
7. Passkey is registered and user continues authentication flow
This enables external applications to seamlessly integrate passkey
registration into their user onboarding
<!--
Please inform yourself about the contribution guidelines on submitting a
PR here:
https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#submit-a-pull-request-pr.
Take note of how PR/commit titles should be written and replace the
template texts in the sections below. Don't remove any of the sections.
It is important that the commit history clearly shows what is changed
and why.
Important: By submitting a contribution you agree to the terms from our
Licensing Policy as described here:
https://github.com/zitadel/zitadel/blob/main/LICENSING.md#community-contributions.
-->
# Which Problems Are Solved
When deploying the login application behind proxies or using Vercel
rewrites (e.g., `zitadel.com/login` → `login-zitadel-qa.vercel.app`),
the application was using the internal rewritten host instead of the
original user-facing host. This caused several issues:
1. **Broken Password Reset Emails**: Email links contained internal
hosts like `login-zitadel-qa.vercel.app` instead of `zitadel.com`
2. **Inconsistent User Experience**: Users would see different domains
in various parts of the flow
3. **Security Concerns**: Internal infrastructure details were exposed
to end users
4. **Scattered Logic**: Host detection logic was duplicated across
multiple files with inconsistent error handling
# How the Problems Are Solved
Created comprehensive host detection utilities in `/lib/server/host.ts`
and `/lib/client/host.ts`:
**Server-side utilities:**
- `getOriginalHost()` - Returns the original user-facing host
- `getOriginalHostWithProtocol()` - Returns host with proper protocol
(http/https)
The /login route was experiencing issues with React Server Component
(RSC) requests interfering with one-time authentication callbacks. When
users navigated to /login via client-side routing (router.push()),
Next.js automatically triggered _rsc requests that could consume
single-use createCallback tokens, breaking OIDC and SAML authentication
flows.
# Which Problems Are Solved
When users attempt to log in, Next.js automatically makes requests with
the `_rsc=1` query parameter for React Server Components. The current
implementation treats these as server errors:
```typescript
// Before
if (_rsc) {
return NextResponse.json({ error: "No _rsc supported" }, { status: 500 });
}
```
This results in:
- Spurious 500 error logs polluting monitoring systems
- False alerts for server failures
- Difficulty distinguishing real issues from benign RSC requests
# How the Problems Are Solved
This PR implements a comprehensive refactoring that:
- Eliminates RSC interference by providing server actions for internal
auth flow completion
- Separates concerns between external flow initiation and internal flow
completion
- Extracts shared utilities to improve code maintainability and
reusability
- Maintains full backward compatibility for external applications
# Additional Context
## New Architecture
- auth-flow.ts: Shared utilities for auth flow completion with RSC
protection
- flow-initiation.ts: Extracted OIDC/SAML flow initiation logic (~400
lines)
- auth.ts: Server actions for internal components
## Route Handler Simplification
- route.ts: Reduced from ~350 lines to ~75 lines
- External-only focus: Now handles only flow initiation for external
applications
- Removed completion logic: External apps use their own callback URLs
- Enhanced validation: Early RSC blocking and parameter validation
## Flow Logic Improvements
- Early return patterns: Guard clauses eliminate deep nesting
- Better error handling: Specific error messages for different failure
modes
- Fixed SAML flow: Addressed incomplete logic
- Consistent session handling: Unified approach across OIDC and SAML
This PR completely removes Next.js image optimization from the login app
by replacing all next/image components with standard HTML <img> tags and
removing the image optimization configuration.
Closes https://github.com/zitadel/zitadel-charts/issues/381
# Which Problems Are Solved
Users were encountering issue when loading images in dedicated
environments. These happened due to nextjs imaging optimizations
creating different paths for images.
# How the Problems Are Solved
- Removed Next.js Image Optimization Config
- Removed images: { unoptimized: true } configuration from
[next.config.mjs](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html)
This config was redundant since we no longer use next/image components
- Replaced next/image with standard <img> tags
Safari was not creating session cookies during local development,
causing authentication failures. This was due to nextjs default setting
of SameSite cookie property.
We explicitly set "strict" for session cookies now.
Closes#10473
# Which Problems Are Solved
Authentication Issues with Safari in local development
# How the Problems Are Solved
- Cleaner API: Replaced confusing sameSite boolean/string parameters
with iFrameEnabled boolean
- Better logic flow:
iFrameEnabled: true → sameSite: "none" (for iframe embedding)
Production → sameSite: "strict" (maximum security)
This PR removes the Vercel Analytics integration from the login
application to reduce external dependencies and improve privacy.
# Which Problems Are Solved
cleaner csp
# How the Problems Are Solved
- Removed dependency: Uninstalled @vercel/analytics package from
package.json
- Updated layout component: Removed Analytics import and component usage
from layout.tsx
- Updated Content Security Policy: Removed Vercel domains
(https://va.vercel-scripts.com and https://vercel.com) from CSP
configuration in csp.js
Fixed an issue in `isSessionValid()` where users with multiple
configured MFA methods (e.g., TOTP and U2F) would have their sessions
incorrectly invalidated. The function previously used exclusive if-else
logic that only checked the first matching method, causing validation to
fail even when other configured methods were successfully verified.
Closes#10529
# Which Problems Are Solved
[#10529](https://github.com/zitadel/zitadel/issues/10529)
# How the Problems Are Solved
- Replaced exclusive if-else if chain with inclusive validation logic
- Session is now considered valid if ANY configured MFA method has been
verified
- Improved error logging to show all configured methods and their
verification status
Example: A user with both TOTP and U2F configured can now successfully
authenticate using either method, whereas previously the session would
be invalid if they used U2F but TOTP was checked first.
Closes#10498
The registration form's legal checkboxes had incorrect validation logic
that prevented users from completing registration when only one legal
document (ToS or Privacy Policy) was configured, or when no legal
documents were required.
additionally removes a duplicate description for "or use Identity
Provider"
# Which Problems Are Solved
Having only partial legal documents was blocking users to register. The
logic now conditionally renders checkboxes and checks if all provided
documents are accepted.
# How the Problems Are Solved
- Fixed checkbox validation: Now properly validates based on which legal
documents are actually available
- acceptance logic: Only requires acceptance of checkboxes that are
shown
- No legal docs support: Users can proceed when no legal documents are
configured
- Proper state management: Fixed checkbox state tracking and mixed-up
test IDs
---------
Co-authored-by: Stefan Benz <[email protected]>
# Which Problems Are Solved
Integration tests were failing with Minified React error 419 caused by
React 19 Suspense boundary issues during server-side rendering (SSR) to
client-side rendering (CSR) transitions.
# How the Problems Are Solved
The fix handles infrastructure-level SSR errors gracefully while
maintaining proper error detection for actual application issues.
- Added Cypress error handling for React 19 SSR hydration errors that
don't affect functionality
# Additional Changes
Enhanced Next.js configuration with React 19 compatibility
optimizations:
- `optimizePackageImports`: @radix-ui/react-tooltip and @heroicons/react
can have large bundle sizes if not optimized. Such packages are
suggested to be optimized in
https://nextjs.org/docs/app/api-reference/config/next-config-js/optimizePackageImports
- `poweredByHeader`: Not that important. Benefits are smaller HTTP
headers, Tiny bandwidth savings, and more professional appearance due to
cleaner response headers, added it as a "security best practice".
# Additional Context
- Replaces #10611
Fix CSP img-src to allow ZITADEL instance assets
# Which Problems Are Solved
Login app was failing to load images (logos, branding assets) from
ZITADEL instances due to Content Security Policy restrictions. The CSP
img-src directive only allowed 'self' and https://vercel.com, blocking
images from ZITADEL domains like https://login-*.zitadel.app.
# How the Problems Are Solved
- Dynamic CSP configuration: Extract hostname from ZITADEL_API_URL
environment variable
- Fallback support: Use *.zitadel.cloud wildcard when no specific URL is
configured
- Environment-aware: Works across dev/staging/prod without hardcoded
domains
This PR fixes a problem for the SAML provider in console where the
binding selection was not correctly applied when editing existing
providers
# Which Problems Are Solved
- SAML provider binding selection was not correctly applied when editing
existing providers
- Form used untyped reactive forms leading to potential runtime errors
- Hardcoded enum handling made the code fragile to API changes
# How the Problems Are Solved
- Created reusable utility functions (enum.utils.ts) that properly
convert between numeric enum values (from backend) and string keys (for
form controls)
- Improved type safety: Migrated from
UntypedFormGroup/UntypedFormControl to strongly typed
FormGroup<SAMLProviderForm> with FormControl<T>
This PR sets the page title to the same title as the respective pages
and introduces a default title ("Login with Zitadel").
Closes#10282
# Which Problems Are Solved
Missing page title on pages.
# How the Problems Are Solved
Using the hosted translation service, we load and merge properties to
set the page title
---------
Co-authored-by: Livio Spring <[email protected]>
# Which Problems Are Solved
This PR fixes an issue where all features where patched, instead of a
single one. This led to instance overrides which were not intended.
With this change, an update is executed whenever a toggle is hit, only
containing the respective feature, not all.
# How the Problems Are Solved
The console application was overriding the feature settings as an entire
request. A toggle change is now only changing the desired and targeted
feature using partial patches.
# Additional Context
Closes#10459
---------
Co-authored-by: Elio Bischof <[email protected]>
Fix: Pin buf protoc plugin versions to resolve runtime protobuf
compatibility issues
# Which Problems Are Solved
The console application was experiencing a runtime error "requireUtf8 is
not a function" when the authentication service attempted to deserialize
protobuf messages. This error started occurring recently due to
automatic updates of buf protoc plugins.
# How the Problems Are Solved
pinning of the versions in buf.gen.yml and package.json
Closes#10413
This PR changes the logout success page of the V2 login to
`/logout/done` and accepts both `post_logout_redirect` as well as
`post_logout_redirect_uri` as a param for the post logout url.
# Which Problems Are Solved
The new Login V2 aligns with the login V1 now.
Accepts `post_logout_redirect` as well as `post_logout_redirect_uri` as
a param for the post logout url.
# How the Problems Are Solved
Both search params are now accepted.
# Which Problems Are Solved
The new login UI user case sensitive matching for usernames and email
addresses. This is different from the v1 login and not expected by
customers, leading to not found user errors.
# How the Problems Are Solved
The user search is changed to case insensitive matching.
# Additional Changes
None
# Additional Context
- reported by a customer
- requires backport to 4.x
---------
Co-authored-by: Livio Spring <[email protected]>
This PR changes the cookie settings for the SAML post bindings. It sets
"secure": true and "SameSite" to "Strict" for production environments.
It removes the fallback serialization as we have proven this is not
required anymore.
This PR implements a SAML cookie which is used to save information to
complete the form post. It is primarily used to avoid sending the
information as url search params and therefore reducing its length.
# Which Problems Are Solved
This PR addresses a bug in Console V2 APIs, specifically when the
feature toggle is enabled, which caused incorrect organization context
assignment during new user creation.
Co-authored-by: Ramon <[email protected]>
This PR ensures that the list of recent sessions has no duplicate
entries.
To ensure the sessions are unique, we create a map using the loginName
property.
---------
Co-authored-by: conblem <[email protected]>
This PR implements a component which is used to render the feature
settings in a generic way.
All features besides`loginV2` and `improvedPerformance` are rendered.
Note: The feature flags are not autogenerated as the console needs
descriptions for the respective features and there are multiple types
where additional fields like text input is required
Closes#9090
---------
Co-authored-by: conblem <[email protected]>
# Which Problems Are Solved
When registering passkeys or u2f methods as second factor, some users
pressed the "Enter" key, rather than clicking the submit button. This
method has bypassed the execution of the device registration and
encoding scripts, resulting in the form being submitted without the
necessary encoded values.
# How the Problems Are Solved
This PR ensures that device registration is always executed and the
required information are submitted in the form regardless of pressing
"Enter" or clicking the button.
# Additional Changes
None
# Additional Context
- closes#6592
- closes#2910
This fixes a problem where the org settings were hidden.
The console reads the context from either a query param or the local
storage. When one context was found, it executed a single request with
orgId filter. This let to a single org and then to a hidden org setting,
as we hide org settings for instances with a single result.
This reduces the initial payload of the `listMyProjectOrgs` to get the
active org by setting the limit of the initial orgs to 100.
Partial of #8272
---------
Co-authored-by: Livio Spring <[email protected]>
Max PeintnerandGitHub
