mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-18 05:52:51 +00:00
main
185
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  Max PeintnerandGitHub
|
9e1b85fa91 |
fix(login): forward login_hint to the external IdP (#12760)
# Which Problems Are Solved Login V2 never forwards the OIDC `login_hint` to an external identity provider. The user enters their identifier once at ZITADEL, is redirected to the IdP, and has to type it again because the IdP's authorize request contains no `login_hint`. Login V1 has done this since #6899 (`sessionParamsFromAuthRequest`), and the backend half for V2 exists since #11552 (`RedirectURLs.login_hint` on `StartIdentityProviderIntent`), but none of the three places in the login app that start an IdP intent set it. # How the Problems Are Solved Every call to `startIdentityProviderFlow` now sets `urls.loginHint`, mirroring the priority Login V1 uses: - `sendLoginname`: when the user is already known and linked to exactly one IdP, the hint is the username the IdP knows the user by (`IDPLink.userName`), falling back to the typed login name (with the org domain suffix re-attached). When an org's single active IdP triggers the redirect, the hint is the login name. - `handleOIDCFlowInitiation`: when the auth request selects an IdP via `urn:zitadel:iam:org:idp🆔<id>`, the hint is `authRequest.loginHint`. - `redirectToIdp` (the user clicks an IdP button): `SignInWithIdp` gets an optional `loginHint` prop rendered as a hidden form field. The loginname page passes the login name it was prefilled with from `login_hint`; the authenticator setup page passes the session's login name when linking an IdP to an existing user. Unit tests cover all three call sites, including the linked-username priority and the empty-hint case. Closes #12080 Based on #12683 by @aarontraynor |
||
|
Max PeintnerandGitHub
|
ceba26f434 |
fix(login): verify API credentials at startup instead of in readiness probe (#12742)
# Which Problems Are Solved The Login V2 readiness endpoint `/ui/v2/login/ready` performs an authenticated `SettingsService.GetGeneralSettings` call on every invocation. This only affects self-hosted Login V2 deployments that probe the endpoint periodically, for example via the Helm chart's readiness and startup probes, the Docker `HEALTHCHECK`, or a custom HTTP probe. In those setups every login replica continuously issues authenticated API calls that pass through the access-log interceptor and are treated as regular authenticated requests of the instance, although they are only probe traffic. The login hosted by ZITADEL Cloud is not affected, and neither are self-hosted deployments that do not probe `/ready`. Independent of the counting, validating credentials on every probe is unusual: readiness probes are meant to report whether a replica can serve traffic, while configuration errors such as invalid credentials are better caught once at startup. # How the Problems Are Solved The readiness endpoint now only checks that the ZITADEL API is reachable and ready, using the API's unauthenticated `/debug/ready` endpoint. That endpoint is served outside the access-log and quota interceptors, so probe traffic is no longer recorded. `CUSTOM_REQUEST_HEADERS` are applied to the readiness request as they are to gRPC requests. The credential check moves to process startup: `register()` in `instrumentation.ts` calls the new `verifyApiCredentials()` once, using the same auth and transport path as real requests. If the API rejects the credentials (`Unauthenticated`/`PermissionDenied`) or no credentials are configured, the process exits with a clear error so misconfiguration is visible immediately. If the API is not reachable at startup, a warning is logged and the process continues; reachability remains the job of the readiness probe and `ZITADEL_API_AWAITINITIALCONN`. Unit tests cover the readiness route, the credential check result mapping, and the startup behavior of `register()`. No changes to the Helm chart or Dockerfile are required. Self-hosted deployments pick up the fix with the next login image; until then, the probe interval can be increased to reduce the number of calls. |
||
 
|
dbbab75420 |
Merge commit from fork
* fix(security): prevent unauthenticated IDP-linking account takeover Two distinct defects allowed an attacker to bind their own external identity to a victim's account and, because external IDP links are globally unique (first claim wins), hijack the victim's future federated logins. LoginV2: resolveUserIdFromSession returned the session's user id after only a null check, trusting an "identify-only" session (login name submitted, no verified primary factor). An unauthenticated attacker who knew a victim's login name could drive explicit linking against that session. Gate it on isSessionValid so only a fully authenticated session can link. Backend: AddUserIDPLink skipped the user-write permission check when the caller targeted their own account (userID == ctx user). Because the external subject is caller-supplied and unverified, this let any authenticated user self-link an unproven identity. Make the permission check unconditional. The login/federation flow uses a service account (userID != ctx user) and already took the permission branch, so it is unaffected; verified self-service linking goes through the IDP-intent flow. Adds a LoginV2 regression test (identify-only session is rejected) and the first command-level test for AddUserIDPLink (self-link without permission is denied). Co-Authored-By: Claude Opus 4.8 <[email protected]> * test(user_idp_link): address review on AddUserIDPLink hardening - add success regression cases for AddUserIDPLink (self-link with permission, other-user link with permission) so the login-client and managed-admin paths are pinned and the assert.NoError branch is live - add an integration case: UserCTX self-linking on its own account is now denied - document the intentional no-permission-check invariant on BulkAddedUserIDPLinks (verified Login V1 flow only; not API-exposed) Co-Authored-By: Claude Opus 4.8 <[email protected]> Claude-Session: https://claude.ai/code/session_01RUhwzSqHhycHNAJEfMcrdd * fix(login): authorize IDP linking via enrollment guard, not isSessionValid Replace the isSessionValid gate in resolveUserIdFromSession with getEnrollmentAuthorizationError. isSessionValid requires a verified primary factor, which rejected the legitimate "link an IDP as the first authenticator" onboarding flow (a freshly verified user with no credentials yet). The enrollment guard authorizes when the session has a verified, non-expired primary factor OR the user has zero auth methods and passed the user-verification check (email/invite-code proof bound to the browser fingerprint) — closing the identify-only ATO while preserving first-authenticator linking. Replace the single mocked rejection test with four that run the real guard: identify-only + has credentials -> rejected; identify-only + no credentials + no verification check -> rejected; expired primary factor -> rejected; identify-only + no credentials + verification check -> allowed. Co-Authored-By: Claude Opus 4.8 <[email protected]> Claude-Session: https://claude.ai/code/session_01T24WwsRLbaC7aHxBmyznnd --------- Co-authored-by: Claude Opus 4.8 <[email protected]> |
||
 Matías RacedoandGitHub
|
78be618357 |
fix(login): translate authentication and OTP strings (#12668)
Closes #12481 Closes #12226 # Which Problems Are Solved Login V2 still contained several hardcoded authentication-method and OTP strings, preventing them from following the selected locale or being overridden through custom Login translations. Additionally, the password-reset flow already referenced `password.errors.passwordResetNotAllowed`, but the key was missing from the Login V2 translations, causing the raw translation key to be displayed when password reset is disabled. # How the Problems Are Solved * Replaced the hardcoded authentication-method labels with Login V2 translation keys. * Replaced the OTP challenge and verification fallback messages with translated values. * Reused the existing `otp.verify.resendCode` translation for the resend button's accessible label. * Added `password.errors.passwordResetNotAllowed`. * Added the new keys to all supported Login V2 locales and mirrored them in `internal/query/v2-default.json` so frontend and API-provided default translations remain consistent. * Added unit coverage for the translated authentication labels and OTP failure paths. # How the Changes Are Tested * `pnpm nx run @zitadel/login:test-unit` * `pnpm nx run @zitadel/login:lint` * `pnpm nx run @zitadel/login:build` * `pnpm nx run-many --projects @zitadel/login @zitadel/client @zitadel/proto --targets lint build test` * Manually verified Login V2 with multiple locales, including authentication-method labels, OTP failure fallbacks, and the disabled password-reset flow. |
||
|
3c746281f1 |
fix(login): show account selection after RP-initiated logout (#12638)
**Supersedes #12471** by @conblem — same fix, rebased onto current `main` with conflicts resolved and review feedback applied. Original commits are preserved, all credit to @conblem. Closes #12252 ### Problem After an RP-initiated logout (`end_session` with `id_token_hint`), Login V2 redirected straight to `/loginname` instead of showing the account picker like Login V1. The `sessions` cookie still referenced the previous accounts, but their server-side sessions had been terminated, so `listSessions` returned nothing and the flow treated the browser as having no accounts at all. ### Solution - `handleOIDCFlowInitiation` now checks the `sessions` cookie (`hasCookieAccount`) when no live session is eligible for the request's organization. If the cookie still knows an account and the RP passed no `login_hint`, the user is sent to `/accounts` instead of `/loginname`. `prompt=none` is excluded since it must never render UI. - `/accounts` synthesizes an (invalid) `Session` for each cookie entry that has no live counterpart, so the account is still listed and a click re-authenticates via `/loginname` → password in one step. - `clearSession` prunes the cookie entry when the server reports the session as already gone (`NotFound` / `PermissionDenied`), so stale cards can be dismissed. Any other error is rethrown so a still-valid server session is never silently orphaned. - `getAllSessionCookieIds` is now a thin wrapper over `getAllSessions`; `FlowInitiationParams.sessionCookies` is typed as `Cookie[]`. - Tests: new `describe` block covering the cookie fallback, `login_hint` precedence, `prompt=none`, org-scope matching/mismatch, and `SELECT_ACCOUNT` / default prompt with live sessions filtered out by org. - Also adds `.claude/`, `.cursor/`, `.codex/`, `.windsurf/`, `.copilot/`, `.aider*` to `.gitignore`. --------- Co-authored-by: conblem <[email protected]> |
||
|
324cc54d9a |
fix(console): support Zitadel Support IDP (#12619)
# Which Problems Are Solved
The backend and the new login already support the dedicated ZITADEL IdP
template
(`AddZitadelProvider`/`UpdateZitadelProvider`, `PROVIDER_TYPE_ZITADEL`,
`InstanceRolesInfo`),
but the Console does not expose it:
- A ZITADEL provider cannot be created or edited from the Console,
neither at instance nor at
organization level — it is missing from the "add provider" list in the
IdP settings.
- Providers created through the API are listed in the IdP table as
`coming soon` (the type
`@switch` has no `PROVIDER_TYPE_ZITADEL` case) and the row has no detail
route, so an existing
provider cannot be opened.
- `InstanceRolesInfo` — the organization ID/domain pairs that drive
instance-role synchronization
for instance-level providers — is not configurable outside the API.
# How the Problems Are Solved
- Added `ProviderZitadelComponent`
(`console/src/app/modules/providers/provider-zitadel/`),
modeled on the generic OIDC provider component:
- Form for `name`, `issuer`, `clientId`, `clientSecret` and `scopesList`
(chip input, defaulting
to `openid`, `profile`, `email`), plus the shared
`cnsl-provider-options` block.
- On edit the client secret is optional and is only sent when the
"update client secret"
checkbox is set.
- Reuses `cnsl-provider-next` for the callback URL, activation and "what
now" flow.
- Added the instance role mapping section, rendered only for
instance-level providers
(`serviceType === ADMIN`), since the API rejects `instance_roles_info`
on organization-scoped
ZITADEL providers. Entries are added as organization ID + organization
domain pairs and are
submitted as `InstanceRolesInfo`; both values are required and are
matched together on login.
- Added `addZitadelProvider`/`updateZitadelProvider` to `AdminService`
and `ManagementService`
wrapping the existing gRPC calls.
- Declared the component in `providers.module.ts` and mapped
`PROVIDER_TYPE_ZITADEL` to the
`zitadel` path in `providers-routing.module.ts`, so
`/instance/provider/zitadel/...` and
`/org/provider/zitadel/...` resolve for both create and edit.
- Added a ZITADEL tile to the "add provider" list in the IdP settings
and a
`PROVIDER_TYPE_ZITADEL` case to the IdP table;
`IdpTableComponent.routerLinkForRow` now returns
the detail route for ZITADEL rows.
# Additional Changes
- Added the new i18n keys `IDP.CREATE.ZITADEL.TITLE`/`DESCRIPTION`,
`IDP.INSTANCEROLESINFO`,
`IDP.INSTANCEROLESINFO_DESC`, `IDP.ORGANIZATIONID` and
`IDP.ORGANIZATIONDOMAIN` to all 22
Console locale files with actual translations instead of English
fallbacks.
- The provider tile, table entry and detail header use the colored
ZITADEL logo assets
(`zitadel-logo-solo-light.svg` in the dark theme,
`zitadel-logo-solo-dark.svg` in the light
theme), consistent with the header, rather than the monochrome
`*-solo-*-icon.svg` variants.
- Additional sync roles trigger for the support IDP to behave correctly
on first login after a disable/enable cycle — where auto-linking jumps
in — but not required for the link to be established.
# Additional Context
- Closes #11825
- Part of the "Zitadel as an Identity Provider" epic #5127
- Console counterpart to the API work in #12018, #12056 (add), #12371,
#12378, #12384 (update),
#12394 (get/list), #12396 (delete), #12422 (active IdPs) and to the
login support in #12469,
#12530 and #12568
---------
Co-authored-by: Livio Spring <[email protected]>
|
||
|
|
a1a4572303 |
chore(deps): update npm dependencies and clean up pnpm overrides (#12592)
# Which Problems Are Solved Several dependencies across the workspace had fallen behind their latest patch releases, and the override list in pnpm-workspace.yaml had drifted: many of the 28 entries were no longer needed because the dependency tree had already moved past them, while a few enforced outdated version floors. # How the Problems Are Solved Direct dependencies were updated where newer patch releases were available: `@angular/*` → ^21.2.19, `next` → 16.2.11 (docs and login, incl. `@next/eslint-plugin-next`), `nx` → 22.7.7, and `js-yaml` → ^4.3.1 / `postcss` → ^8.5.23 in docs. The lockfile was regenerated from scratch so all transitive dependencies resolve to the newest versions within their allowed ranges. With that in place, the override list was rebuilt down to the 8 entries that are still required because a parent package pins an older version (axios and brace-expansion via nx, postcss and sharp via next, esbuild via tsx, uuid via testcontainers, and the two OpenTelemetry packages); the other 20 overrides were removed. A verification pass confirmed the resolved versions stay at or above the floors the removed overrides used to enforce, and `pnpm audit` comes back clean. --------- Co-authored-by: Livio Spring <[email protected]> |
||
|
Max PeintnerandGitHub
|
d488ecb07f |
fix(login): don't prepend base path to absolute IdP URL on login_hint redirect (#12610)
# Which Problems Are Solved When an OIDC authorize request carries a `login_hint` that resolves via domain discovery to an organization configured to auto-redirect to a single external IdP, Login V2's server-side flow initiation returns a malformed `Location` header: the login base path is concatenated with the absolute IdP authorize URL without a separator (e.g. `https://<instance>/ui/v2/loginhttps://login.microsoftonline.com/...`). The flow ends in `{"code":5,"message":"Not Found"}` and the IdP is never contacted. The same IdP works when the user submits the login name interactively, because the client-side handler distinguishes external URLs; only the server-side `login_hint` fast-path introduced in #12431 is affected. Additionally, the same fast-path only handled the `redirect` response shape from `sendLoginname`. When the discovered organization's IdP is SAML with POST binding, `sendLoginname` returns `samlData` (form fields instead of a URL), which was silently ignored — the user fell back to the prefilled `/loginname` screen instead of being signed in silently, unlike the client-side flow, which auto-submits the SAML AuthnRequest form. # How the Problems Are Solved `resolveLoginHint` passed every redirect returned by `sendLoginname` through `constructUrl`, which unconditionally prepends `NEXT_PUBLIC_BASE_PATH` and assumes a relative path. It now checks `isExternalUrl` first: absolute URLs are validated with `isSafeRedirectUri` (blocking `javascript:`/`data:`/etc., falling back to `/loginname` if unsafe) and redirected as-is, while relative paths keep being resolved against the base path — matching the handling already used in the idp-scope branch of `handleOIDCFlowInitiation` and in the client-side `handleServerActionResponse`. `resolveLoginHint` also handles the `samlData` response shape now: after validating the target URL with `isSafeRedirectUri`, it responds with the same auto-submit HTML form used by the existing SAML flows, so a `login_hint` resolving to a POST-binding SAML IdP completes silently as well. Since this form was previously duplicated inline three times in `flow-initiation.ts`, it is extracted into a shared `buildAutoSubmitFormResponse` helper used by all call sites. Regression tests cover the absolute-URL redirect (fails on the previous code with the exact malformed URL), the SAML POST auto-submit response, and the unsafe-scheme fallbacks for both shapes. |
||
|
a4266fa7fc |
Merge commit from fork
* fix(login): strip returnCode from browser supplied session challenges The updateOrCreateSession server action forwarded the browser's challenges object to the session API verbatim and returned the resulting challenges in its response. A party who knew only a victim's login name could create an identify-only session, request OTP-Email and OTP-SMS challenges with the returnCode delivery type, and read both plaintext codes straight out of the server action response. sanitizeChallenges forces returnCode off before anything is forwarded. It is applied in createSessionAndUpdateCookie and setSessionAndUpdateCookie rather than in the action itself, so every caller including sendPasskey is covered by one gate. An OTP-Email returnCode request is rewritten to sendCode rather than dropped, so the legitimate flow still completes and the code is delivered to the user; WebAuthN challenges carry no code and pass through untouched. The action response is also narrowed to the WebAuthN challenge. That is redundant while the sanitizer holds, but it keeps "no OTP code crosses this boundary" a local, readable property. Co-Authored-By: Claude Opus 5 <[email protected]> * test(login): assert session challenges are sanitized before reaching the API challenges.test.ts covers what sanitizeChallenges does, but nothing asserted that cookie.ts actually calls it. A refactor could drop either call site and the whole suite would still pass, silently reopening the hole. Covers both entry points to the session API by asserting on the challenges the mocked client receives, so the test fails if the sanitizer is ever bypassed. Co-Authored-By: Claude Opus 5 <[email protected]> --------- Co-authored-by: Claude Opus 5 <[email protected]> |
||
|
Max PeintnerandGitHub
|
a331e5b7ba |
fix(login): redirect unknown users to external IdP after domain discovery when enumeration protection is active (#12581)
# Which Problems Are Solved A `login_hint` that resolves an organization via domain discovery but matches no existing user is no longer automatically redirected to the organization's external IdP when enumeration protection (`ignoreUnknownUsernames`) is active on the request context. #12369 combined the unknown-user IdP redirect into a single condition, but gated it with `&& !ignoreUnknownUsernames`: ```ts if ((!effectiveLoginSettings?.allowLocalAuthentication || discoveredOrganization) && !ignoreUnknownUsernames) { ``` Since the flag is resolved from the pre-discovery context (the instance default settings — during domain discovery there is no organization context yet), enabling enumeration protection instance-wide disables the redirect even for IdP-only organizations (`allowLocalAuthentication: false`). The flow falls through to `preventUserEnumeration()` and strands the user on a decoy Password screen for an account that does not exist; the Back button re-enters the auto-submit loop and dead-ends identically. This breaks silent-SSO first logins where the external IdP is supposed to create the account on first authentication (Login V2). The guard is also counterproductive on its own terms: existing users of the same org still auto-redirect to the IdP, so the divergent treatment acts as an enumeration oracle — redirect means the user exists, password screen means it doesn't. And it protects nothing in practice, since the IdP remains reachable manually via the account switcher → login-name screen → IdP button. # How the Problems Are Solved Split the condition by what known users of the resolved organization actually experience, so unknown usernames always mimic the known-user flow: ```ts if ( !effectiveLoginSettings?.allowLocalAuthentication || (discoveredOrganization && !ignoreUnknownUsernames) ) { ``` - **Local authentication disabled (IdP-only org):** redirect unknown usernames to the single allowed IdP regardless of `ignoreUnknownUsernames`. Known users are auto-redirected there, so the identical redirect is precisely what keeps unknown usernames indistinguishable — and it restores first-login account creation via the external IdP. - **Local authentication enabled:** known (password) users see the password screen, so the decoy password screen remains the indistinguishable behavior and enumeration protection keeps gating the discovery-based IdP redirect, as introduced by #12369. Adds regression tests for both cases: domain discovery into an IdP-only org with `ignoreUnknownUsernames: true` expects the IdP redirect; discovery into a local-auth org expects the decoy `/password` redirect with no IdP flow started. |
||
|
Max PeintnerandGitHub
|
790244dd49 |
feat(login): synchronize instance roles for Zitadel identity provider (#12568)
# Which Problems Are Solved - Logins through the new login via a Zitadel identity provider with `instanceRolesInfo` configured (e.g. support access) create/update the user, but the instance member roles from the `urn:zitadel:iam:org:project:roles` claim are never assigned — that synchronization only exists in the login v1 flow. Support users therefore end up without any permissions. # How the Problems Are Solved - New `syncInstanceRolesFromIdpIntent` in the login, called after user auto-creation and on existing-user logins. It mirrors the v1 filtering: roles are only honored for ZITADEL IdPs with `instanceRolesInfo`, when granted in a configured organization (matched on ID and domain) and using an instance role key (`IAM_` prefix). Memberships are written merge-only via the v2 `InternalPermissionService` (existing roles are never removed), and a failed sync logs a warning without blocking the login. # Additional Changes - Unit tests for the claim-to-role filtering. # Additional Context - Part of the "ZITADEL as an Identity Provider" epic: #5127 - Follow-up for PR #xxx (ZITADEL provider sign-in button in the new login) |
||
|
Max PeintnerandGitHub
|
ba3a45bee4 |
fix(login): treat user-verified passkey as fulfilling MFA in session validity check (#12575)
# Which Problems Are Solved
Users with a passkey plus an additional configured second factor (TOTP /
OTP Email / OTP SMS) get stuck on the passkey verification page: the
WebAuthn ceremony succeeds, but the continue button just spins and the
user is redirected back to `/passkey` indefinitely. Re-registering the
passkey or switching to a private window does not help.
Since the MFA hardening of `isSessionValid` (
|
||
|
30434d176c |
feat(login): Sign in with Zitadel (#12530)
Closes #11824 # Which Problems Are Solved The backend supports the dedicated ZITADEL identity provider template (`AddZitadelProvider`, `IDENTITY_PROVIDER_TYPE_ZITADEL`), but the new login (login v2) cannot yet handle providers of this type: A configured and activated ZITADEL IdP is not rendered as a sign-in option, because the provider type is missing from the login's component mapping. # How the Problems Are Solved - Regenerated `@zitadel/proto` (`settings/v2/login_settings_pb` in `types`, `es` and `cjs`) so `IdentityProviderType.ZITADEL = 13` is available (`idp/v2` was already up to date). - `apps/login/src/lib/idp.ts`: - `idpTypeToSlug` maps `ZITADEL` to the `zitadel` slug, used by the generic `/idp/[provider]/process|failure` routes (no route changes needed). - `idpTypeToIdentityProviderType` maps `IDPType.IDP_TYPE_ZITADEL` to `IdentityProviderType.ZITADEL`. - Added `SignInWithZitadel` button (`apps/login/src/components/idps/sign-in-with-zitadel.tsx`) with the Zitadel logo as inline SVG: the brand gradient is theme-independent, accents use `currentColor` to adapt to light/dark, consistent with the other provider buttons. - Registered the Zitadel type in the provider-to-component mapping in `sign-in-with-idp.tsx`. No changes to the IdP intent handling are required: user auto-creation/auto-update consume the pre-mapped `user_action.create_user` / `update_user` from `RetrieveIdentityProviderIntent`, which the backend fills for the Zitadel provider like for any generic OIDC provider. # Additional Changes - Added the `signInWithZitadel` i18n key ("Sign in with Zitadel") to all 15 locale files. - Extended `idp.test.ts` with the new slug and type mappings and added the Zitadel type to the exhaustive enum-coverage tests (45 tests passing). # Additional Context - Part of the "Zitadel as an Identity Provider" epic: #5127 - Enables the customer-portal "support access" flow, where support staff sign in to a customer instance via a pre-configured Zitadel Support IdP --------- Co-authored-by: Copilot Autofix powered by AI <[email protected]> |
||
|
|
464d1cb655 |
fix(login): resolve unknownContext error on password page caused by inconsistent ignoreUnknownUsernames handling (#12512)
# Which Problems Are Solved The `/password` page (and related password pages) can show the `unknownContext` error even though the user was resolved correctly and login completes fine. Two causes: 1. `sendLoginname` used two different `ignoreUnknownUsernames` sources: session creation was gated on the **user's org** login settings, while the redirect's `loginName` masking and enumeration guards were gated on a **caller-supplied flag** reflecting the request context (instance or org scope). Whenever the two diverge — e.g. `ignoreUnknownUsernames` enabled on the instance but not on the user's org, or the reverse — the redirect carries a `loginName` that doesn't match the session cookie (or no session is created at all), so the `/password` page can't load the session and renders `unknownContext`, while password submission still succeeds via its user-search fallback. This affects every caller of `sendLoginname` — the manual `/loginname` form as well as the server-side `login_hint` resolution; it was most reproducible with `login_hint`, since that path resolves context settings at the instance level, maximizing the chance of divergence with an org-level policy. 2. The password pages tried to re-derive "was enumeration protection applied?" from login settings to suppress the error — but they resolve settings from a different context than `sendLoginname` (falling back to the default organization instead of the instance), so any org-level custom policy made the suppression misfire. More fundamentally, the alert was keyed on a failed session lookup, which is not an error state: under enumeration protection no session exists by design, and the forms recover without one (`sendPassword` falls back to user search; `/password/set` works via code + userId). # How the Problems Are Solved `sendLoginname` no longer accepts `ignoreUnknownUsernames` from the caller. It derives a single constant server-side from the request-context login settings it already fetches and uses it for every decision in the flow: session creation, `preventUserEnumeration`, the multiple-users branch, the INITIAL-user check, the organization reset, the auth-method guards, and the IdP redirect after domain discovery. Redirect params use `session?.factors?.user?.loginName ?? command.loginName`: when a session exists, its loginName goes in the URL so the next page always finds the session cookie; when protection applies, no session (and no session cookie) is created and the raw input is echoed, keeping known and unknown users fully indistinguishable — including the previously observable `Set-Cookie` difference. `UsernameForm` and `resolveLoginHint` stop forwarding the flag, which also removes the redundant `getLoginSettings` call in `resolveLoginHint`. The password pages no longer consult login settings or the session lookup for the `unknownContext` error and instead warn only when required input is actually missing (matching the existing pattern on the passkey/mfa/u2f pages): `/password` and `/password/change` when no `loginName` searchParam is present, `/password/set` when neither `loginName` nor `userId` is present. A missing session alone no longer triggers the error. Verified against a live instance in all four settings combinations (uniform on/off, both divergence directions) including a known-vs-unknown `login_hint` comparison producing byte-identical responses under protection; full unit suite passes. --------- Co-authored-by: Livio Spring <[email protected]> |
||
|
dc1c8620bc |
fix(login): provide hidden username on password set/change forms (#12490)
<!-- 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 The set-password, change-password and set-register-password forms render only password fields — there is no username field inside the `<form>`. Password managers look for a username field adjacent to the password field in order to associate and save the credential. Without one, on these screens they either skip offering to save, or save a password entry with no username attached — so the saved record can't later be matched to the account. The existing sign-in form (`password-form.tsx`) already carries a username field for this reason; the password *creation/change* flows were missing the equivalent. # How the Problems Are Solved Add a username field to each of the three forms so the newly set password is saved against the correct account: - `set-password-form.tsx` and `change-password-form.tsx` use the `loginName`. - `set-register-password-form.tsx` uses the `email`. The field is a real, focusable-excluded `type="text"` input rather than `type="hidden"` — password managers ignore `type="hidden"` fields when looking for a username, so a visually-hidden text input is required. It is: - `readOnly` (avoids a controlled-input warning and user edits), - `tabIndex={-1}` and `aria-hidden="true"` (kept out of the tab order and the accessibility tree), - `className="sr-only"` (visually hidden but present in the DOM), - `autoComplete="username"` (tells the password manager what it is). The value comes from props already passed to each form, so no signatures change. # Additional Changes None. # Additional Context - The username values (`loginName` / `email`) are already available in each component, so this is a purely presentational change with no server-side or API impact. Co-authored-by: Max Peintner <[email protected]> |
||
|
10a66b786b |
fix(login): honour login_hint and skip the auto-submit loop in OIDC flow (#12431)
<!-- 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 An OIDC authorize request that carries a `login_hint` (and no `prompt`) is meant to land the user on a **prefilled** login screen and let them proceed straight to authentication. Two problems prevented that: **1. The hint was dropped when an unrelated session existed.** When the browser held a `sessions` cookie for a *different* account: - The user was redirected to the **account picker** (`/accounts`) instead of the prefilled login-name screen. - The picker listed the already-logged-in, unrelated account(s) — never the user identified by `login_hint`. - The `login_hint` was **silently dropped** (the `/accounts` URL carries no hint), so the typed email was lost and the flow dead-ended on the wrong accounts. In a clean session (no `sessions` cookie) the same request prefilled correctly, which made the bug depend on unrelated pre-existing sessions. **2. The prefilled path was jarring and looped on "back".** Even when the hint *was* honoured, the flow redirected to `/loginname?loginName=…&submit=true`. That page renders the username screen and then **client-side auto-submits** it, so the user sees the username flash on screen, watches "Continue" click itself, and only then lands on the password step. Worse, `/loginname?submit=true` stays in browser history, so pressing **Back** from the password screen re-triggers the auto-submit and bounces the user straight forward again — an inescapable loop with no way to edit the username. # How the Problems Are Solved **Honour the hint (problem 1).** In `handleOIDCFlowInitiation`, the default branch (no `prompt`) already calls `findValidSession`, which filters the browser's sessions by `login_hint` and treats the hint as *selecting the user*. When the hint matches none of the sessions it returns `undefined`, and the remaining `eligibleSessions` (filtered by organization only) are therefore never the hinted user. The fallback previously chose between the loginname screen and the account picker based solely on `eligibleSessions.length === 0`, so a present-but-unrelated session sent the user to `gotoAccounts`, discarding the email. The loginname branch is now also gated on `authRequest.loginHint`, mirroring the existing empty-eligible-sessions branch. **Skip the flash and the loop (problem 2).** Instead of bouncing through `/loginname?submit=true` and relying on client-side auto-submit, the hint is now resolved **server-side** via `sendLoginname` (the same approach the `Prompt.LOGIN` branch already used) and the user is redirected **straight to the next step** (e.g. `/password`), skipping the `/loginname` screen entirely. This is factored into a shared `resolveLoginHint` helper and applied to all `login_hint` branches (default-prompt, no-session, and the existing `Prompt.LOGIN` path, now deduplicated). When the hint can't be resolved (unknown/ambiguous user, transient error), the flow falls back to a prefilled `/loginname` **without** `submit=true` — a clean screen where the user clicks once — so there is no auto-submit and no back-button loop in any path. ```ts if (!selectedSession || !selectedSession.id) { // login_hint matches no session: resolve it straight to the next step. if (authRequest.loginHint) { const hintResponse = await resolveLoginHint({ request, requestId, loginHint: authRequest.loginHint, organization }); if (hintResponse) { return hintResponse; } } // Prefill loginname (not the account picker) for an unresolved hint or when no session is eligible. if (authRequest.loginHint || eligibleSessions.length === 0) { return gotoLoginname({ request, requestId, loginHint: authRequest.loginHint, organization, orgDomain }); } return gotoAccounts({ request, requestId, organization, orgDomain }); } ``` Resulting behaviour: - `login_hint` set, a session **matches** it → silent auth (**unchanged**). - `login_hint` set, **no** session matches, hint **resolves** → straight to the next step (e.g. `/password`), no `/loginname` flash (**was**: account picker with the hint dropped / a jarring auto-submit screen). - `login_hint` set, hint **can't** be resolved → prefilled `/loginname`, no auto-submit, Back stays editable. - **No** `login_hint` → account picker / loginname exactly as before (**unchanged**). # Additional Changes - `resolveLoginHint` helper extracted in `flow-initiation.ts`; the `Prompt.LOGIN` branch now reuses it instead of duplicating the `sendLoginname` call. - `submit=true` is no longer emitted for the login-name flow, so the client-side auto-submit in `username-form.tsx` is no longer reached from OIDC initiation. - Tests in `flow-initiation.test.ts`: each `login_hint` branch (org-scope-filtered, unrelated-session, no-session) is covered twice — hint resolves → straight to `/password`; hint unresolved → prefilled `/loginname` with **no** `submit=true`. # Additional Context - The org-only `eligibleSessions` check was introduced in #12346, which correctly handled the *empty* case but did not account for a present-but-unmatched `login_hint`; this PR extends that gate. - Per OIDC, `login_hint` is advisory prefill; a client that wants the chooser would send `prompt=select_account`. Resolving the hint server-side also matches how the `Prompt.LOGIN` branch already behaved. --------- Co-authored-by: Max Peintner <[email protected]> Co-authored-by: Max Peintner <[email protected]> |
||
|
|
6fa5c0e662 |
Merge commit from fork
* feat(login): add shared enrollment authorization guard Introduce assertSessionAuthorizedForEnrollment, a single gate that decides whether a session may enroll a new authenticator: it requires a verified primary factor (password, passkey or IDP) on a non-expired session, or, for onboarding, a user with no auth methods plus a prior user-verification check. This mirrors the gate previously inlined only in registerPasskeyLink, which is refactored to reuse the shared helper. It is the foundation for gating the remaining credential-enrollment entry points (GHSA-45f2-5q3r-xgg6). Co-Authored-By: Claude Opus 4.8 <[email protected]> * fix(login): require authentication before WebAuthn/U2F enrollment addU2F and verifyU2F registered a credential for any session that resolved to a user id, including a bare identify-only session created by merely submitting a login name. An unauthenticated attacker who knew a victim's login name could therefore attach an attacker-controlled authenticator to the victim's account and then complete a login as the victim. Both actions now run assertSessionAuthorizedForEnrollment before registering or verifying, so an unauthenticated session is rejected and no credential is persisted. GHSA-45f2-5q3r-xgg6 Co-Authored-By: Claude Opus 4.8 <[email protected]> * fix(login): require authentication before TOTP/OTP enrollment verifyTOTP and the otp/<method>/set page activated a TOTP/OTP factor for any session with a user id, and the u2f/set page rendered the registration form without an authorization check. An identify-only session could thus enroll a second factor on a victim's account. Gate all of them with assertSessionAuthorizedForEnrollment. The setup pages now render the unknown-context/error state instead of enrolling when the session is not authorized. Also guard the method value in the OTP set page, since the added guard branch removes the control-flow narrowing the previous throw provided. GHSA-45f2-5q3r-xgg6 Co-Authored-By: Claude Opus 4.8 <[email protected]> * fix(login): require authentication before legacy (V1) passwordless enrollment The V1 passwordless registration handlers began and verified passwordless setup for any auth request that carried a user id, without checking that a first factor had been verified. An unauthenticated attacker could submit a victim's login name and then POST directly to the passwordless prompt/init endpoints to plant an attacker-controlled passkey, then log in as the victim. Add passwordlessSetupAllowed / CheckPasswordlessSetupAllowed, which permit enrollment only for a legitimate onboarding user (PasswordlessInitRequired) or an auth request whose first factor is already verified, and call it before BeginPasswordlessSetup and VerifyPasswordlessSetup. The verify path is also bound to authReq.UserID instead of the attacker-controllable form field, so a credential cannot be redirected onto a different account. The init-code (mail/onboarding) path is unchanged. GHSA-45f2-5q3r-xgg6 Co-Authored-By: Claude Opus 4.8 <[email protected]> * fix(login): remove never-active legacy (V1) authReq passwordless setup path Supersedes the runtime gate added in the previous commit. Maintainer review (Livio, the original author) and investigation confirmed the auth-request based passwordless *setup* path in the legacy login was a never-active leftover: - The passwordless prompt page (passwordless_prompt.html) has no submit button and no script; it only tells the user to complete setup via the emailed link (the PasswordlessButtonText/NextButtonText/SkipButtonText i18n keys are unused). - Legitimate onboarding for a PasswordlessInitRequired user goes through the emailed init-code flow (authReq == nil, BeginPasswordlessInitCodeSetup / VerifyPasswordlessInitCodeSetup), which is untouched. - The authReq branch (handlePasswordlessPrompt -> BeginPasswordlessSetup / VerifyPasswordlessSetup) was reachable only by a crafted direct POST — the GHSA-45f2-5q3r-xgg6 attack. Rather than gate the dead path, remove it entirely, eliminating the attack surface: - delete handlePasswordlessPrompt and the POST /login/passwordless/prompt route (keep renderPasswordlessPrompt: the informational "use your emailed link" page for PasswordlessRegistrationPromptStep), - make renderPasswordlessRegistration / checkPasswordlessRegistration use only the init-code path, - drop the now-unused AuthRequestRepo.BeginPasswordlessSetup / VerifyPasswordlessSetup (and the interface decls) and the passwordlessPromptUrl template helper; the underlying HumanAddPasswordlessSetup / HumanHumanPasswordlessSetup commands remain (used by the auth-API self-service and the v2 passkey APIs). A crafted POST to /login/passwordless/init carrying an authRequestID but no valid code now falls through to the init-code path and fails. GHSA-45f2-5q3r-xgg6 Co-Authored-By: Claude Opus 4.8 <[email protected]> * check for userverified true as well, cleanup return message --------- Co-authored-by: Claude Opus 4.8 <[email protected]> Co-authored-by: Max Peintner <[email protected]> |
||
|
|
3e94047da7 |
fix(login): redirect to external IdP after domain discovery regardless of registration policy (#12369)
Closes #12021 Closes #12023 # Which Problems Are Solved When a user entered an email on the login page and domain discovery resolved the correct organization, the login flow failed to redirect to the configured external IdP. Instead it returned a "user not found" error or showed the registration page. This happened because the "user not found" decision tree in `sendLoginname` only attempted an IdP redirect when `allowLocalAuthentication` was disabled. If local auth was enabled but `allowRegister` was `false`, the IdP check was skipped entirely. # How the Problems Are Solved Combined the IdP redirect logic into a single block that triggers when either local authentication is disabled **or** domain discovery resolved an organization. The registration policy (`allowRegister`) now only affects local account creation and no longer gates external IdP authentication. --------- Co-authored-by: Copilot Autofix powered by AI <[email protected]> Co-authored-by: Livio Spring <[email protected]> |
||
|
Max PeintnerandGitHub
|
56f4798ed3 |
Merge commit from fork
* add mfa check to session validity check * change session check to check for already set up mfa methods * lint * improve naming * test changes * cleanup continueWithSession fcn |
||
|
|
6bd46c5fb6 |
feat(login): idp userAction oneof (#12433)
Closes #11369 # Which Problems Are Solved During SSO login with an external IdP, Actions v2 lets you manipulate the `RetrieveIdentityProviderIntent` response to shape the user that ZITADEL creates or updates. There was an inconsistency between the two flows: - **First login (user does not exist):** the response carried an `addHumanUser` object (mirroring the deprecated `AddHumanUser` API), which **does** allow setting user `metadata`. - **Subsequent logins (user exists):** the response carried an `updateHumanUser` object (mirroring the deprecated `UpdateHumanUser` API), which does **not** support metadata. As a result, actions could set metadata when creating a user but not when updating one. Customers doing SSO attribute mapping had to make a separate `SetUserMetadata` call on every subsequent login — extra latency and a non-atomic update. The proto/backend already gained a non-deprecated `user_action` oneof (`create_user` → `CreateUserRequest`, `update_user` → `UpdateUserRequest`, both supporting metadata), but the login app was still reading the deprecated flat fields, so the new capability was unreachable from the frontend. # How the Problems Are Solved Migrate the login app's IDP intent handler to consume the new `user_action` oneof, with a fallback to the deprecated fields so older API responses keep working during the transition. - **`zitadel.ts`** — added `createUser` / `updateUser` client wrappers calling the non-deprecated `UserService.CreateUser` / `UserService.UpdateUser` endpoints. - **`idp-intent.ts`** — added three helpers, each preferring `user_action` and falling back to `add_human_user` / `update_human_user`: - `resolveCreateUser` — flat read view for org resolution, required-field checks, and registration-form pre-fill. - `buildCreateUserRequest` — passes the action's `CreateUserRequest` through and injects the resolved `organizationId`; maps the deprecated flat payload into the nested shape on fallback. - `buildUpdateUserRequest` — builds an `UpdateUserRequest` **including metadata** (the fix); deliberately syncs only profile/email/phone/metadata (not username) to preserve existing auto-update behavior and avoid invalidating sessions. - Rewired all handlers (`handleUserExists`, `handleAutoLinking`, `handleAutoCreation`, `handleManualCreation`, `resolveOrganizationForUser`) to use these, and switched auto-create to read `CreateUserResponse.id`. - **Tests** — updated mocks/assertions to the new request shapes and added two cases exercising the `user_action` oneof with metadata (create + update). 817/817 login unit tests pass; no new type errors. # Additional Changes Updated the Actions v2 guide `guides/integrate/actions/testing-response-manipulation.mdx` (the unreleased/`latest` docs) to reflect the new response shape: - Go handler example now manipulates `resp.GetCreateUser()` / `resp.GetUpdateUser()` and appends `user.Metadata`, demonstrating metadata on both flows. - Both JSON payloads switched from `addHumanUser` to the nested `createUser` shape (`human.profile`, `human.email`, `human.idpLinks`, top-level `metadata`). - Added a Callout explaining first-login → `createUser` vs. existing-user → `updateUser`, that both support metadata, and that `addHumanUser`/`updateHumanUser` are deprecated. - Updated the claim-mapping debugging section to the new `createUser.human.profile.givenName` path. Versioned snapshots (`v4.12`/`v4.13`/`v4.14`) were intentionally left unchanged, as they document releases where the old API was correct. --------- Co-authored-by: gayathri <[email protected]> |
||
 
|
1e09b4fc19 |
feat(login): hu translations + I18n consistency v2 (#12447)
# Which Problems Are Solved Fixes i18n consistency and adds HU translations for login v2 # How the Problems Are Solved - Updated i18n files and added hu.json - Moved all translations to v2-default.json --------- Co-authored-by: Dobos Zoltán <[email protected]> Co-authored-by: Liam Neville <[email protected]> |
||
|
|
051506b5bb |
fix(login): prevent crash on a stale session cookie (#12423)
<!-- 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 The `sessions` cookie lifetime is independent of Zitadel's server-side session validity, so a cookie can reference an invalid session. In that case `getSession` throws `not_found` (QUERY-SFeaa). - `loadMostRecentSession` lets that error propagate instead of treating it as "no session", crashing the server render of every page that calls it without its own guard. - Most visibly, the "forgot password" flow landing on `/password/set` throws `[not_found] Session does not exist (QUERY-SFeaa)` (gRPC code 5, HTTP 404) and fails to render. - 12 of the 16 call sites are unguarded and share this crash. # How the Problems Are Solved Catch the error in `loadMostRecentSession` and return `undefined`, unifying "cookie references a dropped session" with the existing "no cookie" case. Every call site already handles an undefined session, either with a graceful fallback or by throwing its own explicit error. ```ts return getSession({ serviceConfig, sessionId: recent.id, sessionToken: recent.token }) .then((resp: GetSessionResponse) => resp.session) .catch((error) => { console.warn("[Session] Could not load most recent session", error); return undefined; }); ``` All `loadMostRecentSession` call sites — **Previous** = behaviour when the cookie referenced an invalid session; **Change** = what this PR does to that call site: | # | Call site | Change in this PR | Previous behaviour (invalid session) | New behaviour | |---|-----------|-------------------|--------------------------------------|---------------| | — | `lib/session.ts` — `loadMostRecentSession` | **Added `.catch` → `undefined`** (core fix) | Threw `not_found` to caller | Resolves to `undefined` | | 1 | `password/set/page.tsx` | none | **Crash** (the reported bug) | Falls back to login-name flow | | 2 | `password/change/page.tsx` | none | **Crash** | `undefined` → `failedLoading` alert if no user | | 3 | `passkey/set/page.tsx` | none | **Crash** | `undefined` → `userId` fallback / `unknownContext` | | 4 | `otp/[method]/page.tsx` | none | **Crash** | `undefined` → `unknownContext` alert | | 5 | `otp/[method]/set/page.tsx` | none | **Crash** (raw `ConnectError`) | `undefined` → own `throw "No session found"` | | 6 | `mfa/page.tsx` | none | **Crash** | `undefined` → `verify.noResults` alert | | 7 | `mfa/set/page.tsx` | none | **Crash** (raw `ConnectError`) | `undefined` → own `throw "Could not get user id from session"` | | 8 | `authenticator/set/page.tsx` | none | **Crash** (raw `ConnectError`) | `undefined` → own throw / `unknownContext` | | 9 | `signedin/page.tsx` | none | **Crash** | `undefined` → renders with `loginName` fallback | | 10 | `u2f/set/page.tsx` | none | **Crash** | `undefined` → `unknownContext` alert | | 11 | `u2f/page.tsx` | none | **Crash** | `undefined` → renders on `loginName` | | 12 | `lib/server/verify.ts` — `verifyTOTP` | none | **Crash** (raw `ConnectError`) | `undefined` → own `throw "No user id found in session."` | | 13 | `password/page.tsx` | **Removed redundant `try/catch`** | Caught locally → `undefined` | `undefined` — unchanged | | 14 | `verify/page.tsx` | **Removed redundant `.catch`** ¹ | Caught locally → `undefined` | `undefined` — unchanged | | 15 | `verify/success/page.tsx` | **Removed redundant `.catch`** | Caught locally → `undefined` | `undefined` — unchanged | | 16 | `passkey/page.tsx` | **Removed redundant `.catch`** (login-name path) | Caught locally → `undefined` | `undefined` — unchanged | Rows 1–12 were unguarded and crashed; the central change fixes them. Rows 13–16 already handled the error locally. # Additional Changes - This makes the four callers that wrapped the call in their own try/catch or `.catch` redundant, so remove that now-dead handling (password, verify, verify/success, passkey). - Add unit tests covering `loadMostRecentSession`: no cookie, success, and the stale-cookie rejection path. ¹ `verify/page.tsx`'s `.catch` also eagerly fetched `loginSettings`; that is already covered by the page's own lazy fetch, so behaviour is unchanged (one cosmetic edge case under `ignoreUnknownUsernames` with both `userId` and `loginName` present — no functional impact). # Additional Context - Session *expiry* alone does not trigger this: expired rows are not removed from the session projection, so `getSession` still returns them. The `not_found` specifically means the session was **removed** server-side (logout, admin/API termination, or a user/org/instance cascade) while the browser still held the cookie. - Mirrors the pattern upstream already applies inline in `verify/page.tsx` (*"ignore error, as we might not have a session yet"*), lifted to the shared function. - **Related issue (not in this PR):** the sibling `loadSessionById` helpers on the `?sessionId=` path (`passkey`, `otp`, `mfa`, `mfa/set`, `signedin`, `authenticator/set`, `u2f`) call `getSession` directly and share the same defect. Lower practical exposure (short-lived in-flow URLs; a clean logout clears the cookie), so a follow-up PR should lift those into a shared `loadSessionById` in `lib/session.ts`. - Prior art: upstream added an equivalent guard to verify/page.tsx in #11130, but the other call sites were never given the same treatment — this PR resolves that inconsistency at the source. Error trace: ``` {"level":"error","message":"⨯ Error [ConnectError]: [not_found] Session does not exist (QUERY-SFeaa)\n at R (.next/server/chunks/ssr/_0uqqxk7._.js:3:25490)\n at <unknown> (.next/server/chunks/ssr/_0uqqxk7._.js:3:26477)\n at next (.next/server/chunks/ssr/_0uqqxk7._.js:3:68112)\n at async (.next/server/chunks/ssr/_0uqqxk7._.js:10:31326)\n at async (.next/server/chunks/ssr/_0uqqxk7._.js:10:33734)\n at async Object.unary (.next/server/chunks/ssr/_0uqqxk7._.js:3:66838)\n at async Object.getSession (.next/server/chunks/ssr/_0uqqxk7._.js:3:72371)\n at async o (.next/server/chunks/ssr/[root-of-the-server]__0msfcq_._.js:1:7440) {\n rawMessage: 'Session does not exist (QUERY-SFeaa)',\n code: 5,\n metadata: Headers {\n 'accept-encoding': 'gzip',\n 'alt-svc': 'h3=\":443\"; ma=2592000',\n 'content-length': '240',\n 'content-type': 'application/json',\n date: 'Wed, 08 Jul 2026 09:06:09 GMT',\n 'strict-transport-security': 'max-age=63072000; includeSubDomains; preload',\n vary: 'Origin',\n },\n details: [\n {\n type: 'zitadel.v1.ErrorDetail',\n value: [Uint8Array],\n debug: [Object]\n }\n ],\n cause: undefined,\n httpStatus: 404,\n isUserError: true,\n digest: '634020356'\n}","timestamp":"2026-07-08T09:06:09.969Z"} ``` --------- Co-authored-by: Copilot Autofix powered by AI <[email protected]> Co-authored-by: Marco A. <[email protected]> Co-authored-by: Liam Neville <[email protected]> |
||
|
aa76c3be27 |
fix(login): keep submit button disabled/loading during password set r… (#12429)
<!-- 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 - On Login V2 after a user sets their password during the invite or reset-password flows and clicks continue, there is a few seconds delay before the redirect occurs because no loading spinner is visible on the button during this delay users assume nothing happened and click continue again. - Clicking the button again starts a duplicate form submission. Since the first request was already fired the second request triggers an error right before the redirect from the first request completion creating a bad user experience # How the Problems Are Solved - Kept the `loading` state active `true` throughout the lifeline of the request which includes the 2-second database consistency delay and the subsequent `sendPassword` verification request. - Added `setLoading(false)` calls only in early-return error handling blocks and at the end of the redirection flow ensuring the button remains disabled and shows the spinner until the redirect happens. # Additional Changes - None # Additional Context - Solves #12416 Co-authored-by: Max Peintner <[email protected]> |
||
  |
8b9d3637fd |
chore(deps): bump the go_modules group across 2 directories with 1 update (#12393)
Bumps the go_modules group with 1 update in the /apps/login/acceptance/idp/saml directory: [golang.org/x/crypto](https://github.com/golang/crypto). Bumps the go_modules group with 1 update in the /apps/login/acceptance/samlsp directory: [golang.org/x/crypto](https://github.com/golang/crypto). Updates `golang.org/x/crypto` from 0.36.0 to 0.52.0 <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/golang/crypto/commit/a1c0d9929856c8aba2b31f079340f00578eda803"><code>a1c0d99</code></a> go.mod: update golang.org/x dependencies</li> <li><a href="https://github.com/golang/crypto/commit/3c7c86938f4541c333d506f719388d9c42d4763d"><code>3c7c869</code></a> ssh: fix deadlock on unexpected channel responses</li> <li><a href="https://github.com/golang/crypto/commit/533fb3f7e4a5ae23f69d1837cd851d35ff5b76ce"><code>533fb3f</code></a> ssh: fix source-address critical option bypass</li> <li><a href="https://github.com/golang/crypto/commit/abbc44d451a6f9236a2bbd26cbcd4d0fec473da3"><code>abbc44d</code></a> ssh: fix incorrect operator order</li> <li><a href="https://github.com/golang/crypto/commit/e052873987615dc96fe67607a9a6adb76311344f"><code>e052873</code></a> ssh: fix infinite loop on large channel writes due to integer overflow</li> <li><a href="https://github.com/golang/crypto/commit/b61cf853a89d82cad68da5e12a6beca2116f8456"><code>b61cf85</code></a> ssh: enforce user presence verification for security keys</li> <li><a href="https://github.com/golang/crypto/commit/9c2cd33e8d96a96133fd6ff732510ebba539c2bd"><code>9c2cd33</code></a> ssh: enforce strict limits on DSA key parameters</li> <li><a href="https://github.com/golang/crypto/commit/890731877d85f71cfdc9554e7a27fec4684fc4c4"><code>8907318</code></a> ssh: reject RSA keys with excessively large moduli</li> <li><a href="https://github.com/golang/crypto/commit/ffd87b4878fa98ca2908ec534e1a410bf095a35e"><code>ffd87b4</code></a> ssh: fix panic when authority callbacks are nil</li> <li><a href="https://github.com/golang/crypto/commit/4e7a7384ecbc8d519f6f4c11b36fa9d761fc8946"><code>4e7a738</code></a> ssh: fix deadlock on unexpected global responses</li> <li>Additional commits viewable in <a href="https://github.com/golang/crypto/compare/v0.36.0...v0.52.0">compare view</a></li> </ul> </details> <br /> Updates `golang.org/x/crypto` from 0.36.0 to 0.52.0 <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/golang/crypto/commit/a1c0d9929856c8aba2b31f079340f00578eda803"><code>a1c0d99</code></a> go.mod: update golang.org/x dependencies</li> <li><a href="https://github.com/golang/crypto/commit/3c7c86938f4541c333d506f719388d9c42d4763d"><code>3c7c869</code></a> ssh: fix deadlock on unexpected channel responses</li> <li><a href="https://github.com/golang/crypto/commit/533fb3f7e4a5ae23f69d1837cd851d35ff5b76ce"><code>533fb3f</code></a> ssh: fix source-address critical option bypass</li> <li><a href="https://github.com/golang/crypto/commit/abbc44d451a6f9236a2bbd26cbcd4d0fec473da3"><code>abbc44d</code></a> ssh: fix incorrect operator order</li> <li><a href="https://github.com/golang/crypto/commit/e052873987615dc96fe67607a9a6adb76311344f"><code>e052873</code></a> ssh: fix infinite loop on large channel writes due to integer overflow</li> <li><a href="https://github.com/golang/crypto/commit/b61cf853a89d82cad68da5e12a6beca2116f8456"><code>b61cf85</code></a> ssh: enforce user presence verification for security keys</li> <li><a href="https://github.com/golang/crypto/commit/9c2cd33e8d96a96133fd6ff732510ebba539c2bd"><code>9c2cd33</code></a> ssh: enforce strict limits on DSA key parameters</li> <li><a href="https://github.com/golang/crypto/commit/890731877d85f71cfdc9554e7a27fec4684fc4c4"><code>8907318</code></a> ssh: reject RSA keys with excessively large moduli</li> <li><a href="https://github.com/golang/crypto/commit/ffd87b4878fa98ca2908ec534e1a410bf095a35e"><code>ffd87b4</code></a> ssh: fix panic when authority callbacks are nil</li> <li><a href="https://github.com/golang/crypto/commit/4e7a7384ecbc8d519f6f4c11b36fa9d761fc8946"><code>4e7a738</code></a> ssh: fix deadlock on unexpected global responses</li> <li>Additional commits viewable in <a href="https://github.com/golang/crypto/compare/v0.36.0...v0.52.0">compare view</a></li> </ul> </details> <br /> Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/zitadel/zitadel/network/alerts). </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
|
bc9333aef9 |
chore: update npm dependencies (#12375)
# Which Problems Are Solved - npm dependencies across the monorepo are behind current patch/minor releases. - Transitive dependencies are pinned to older versions by parent packages (karma, nx, @changesets/cli, etc.). - Console build fails after the Angular toolchain update because `angular.json` references assets outside the workspace root. # How the Problems Are Solved - Bumps `@angular/*` to `^21.2.17` in console. - Bumps `js-yaml` to `^4.2.0` in docs. - Bumps `concurrently` to `^10.0.3` in login. - Adds pnpm overrides for transitive deps that cannot be bumped directly (ws, undici, minimatch, esbuild, dompurify, qs, and others). # Additional Changes - Removes 10 overrides that are no longer needed after parent packages resolve to newer versions. - Updates 4 existing overrides (`tar`, `js-yaml`, `dompurify`, `brace-expansion`) to match current upstream ranges. - 2 low-severity findings remain via the abandoned `raw-loader` package in docs (peer dep resolution; no upstream fix without replacing `raw-loader`). - Fixes console build: replaced the `angular.json` asset glob `../apps/docs/public/img/tech` with a `prebuild` script that copies tech images into `src/assets/docs/img/tech`. **Verify at runtime that tech images on project grant / integration pages still load.** # Additional Context - Overrides remain where parent packages still pin older transitive versions. - The `angular.json` asset path issue predates this PR (not introduced by the Angular bump). --------- Co-authored-by: Livio Spring <[email protected]> |
||
|
|
1beabed8cf |
fix(login): preserve org domain suffix through account chooser navigation (#12304)
Closes #12024 # Which Problems Are Solved When the login flow is started with an `urn:zitadel:iam:org:domain:primary:{domain}` scope, the resolved domain suffix is lost if the user navigates through the account chooser (e.g. clicking "Use another account"). This causes the login to fail with "User not found" because the organization can no longer be resolved. Additionally, the `hideLoginNameSuffix` branding setting was never respected by the login app. # How the Problems Are Solved - Forward the `orgDomain` parameter through `gotoAccounts()` and the `/accounts` page, so it survives navigation to `/loginname` — the same way `organization` and `requestId` are already forwarded. - Respect `BrandingSettings.hideLoginNameSuffix`: when enabled, the `@domain.com` suffix is hidden from the input UI but still used internally for user search. --------- Co-authored-by: Livio Spring <[email protected]> |
||
|
|
e6aaea563e |
fix(login): migrate legacy Tailwind v4 opacity utilities and fix checkbox contrast color (#12360)
# Which Problems Are Solved 1. **Secondary button hover effect** was rendering a solid white/gray background instead of a subtle transparent overlay. The legacy `bg-opacity-*` utility (e.g. `hover:bg-gray-500 hover:bg-opacity-20`) doesn't compose with `bg-*` in Tailwind v4 — the opacity is ignored, leaving a solid color. The same issue affected `ring-opacity-*` and `border-opacity-*` across other components. 2. **Checkbox checkmark color** was hardcoded to white (`fill='white'` in the SVG), ignoring the theme's primary contrast color. On themes with a light primary color, the white checkmark was invisible. # How the Problems Are Solved 1. Migrated all legacy opacity utilities to the Tailwind v4 slash syntax: - `hover:bg-gray-500 hover:bg-opacity-20` → `hover:bg-gray-500/20` - `ring-primary-light-500 ring-opacity-60` → `ring-primary-light-500/60` - `focus:ring-opacity-50` + `focus:ring-indigo-200` → `focus:ring-indigo-200/50` - Removed redundant `border-opacity-20` where `border-black/10` was already applied 2. Replaced the static `background-image` checkbox SVG with a `mask-image` + `::after` pseudo-element approach. The checkmark color now uses `var(--theme-light-primary-contrast-500)` / `var(--theme-dark-primary-contrast-500)`, so it dynamically follows the theme's contrast color. --------- Co-authored-by: Livio Spring <[email protected]> |
||
|
Max PeintnerandGitHub
|
92ea32a34d |
fix(login): use correct requestId with oidc_ prefix in Prompt.LOGIN + loginHint flow (#12376)
Closes #11946 # Which Problems Are Solved - OIDC redirect is broken when `Prompt.LOGIN` + `loginHint` is used — the user lands on `/signedin` instead of being redirected to the OIDC client's callback URL (fixes #11946) # How the Problems Are Solved - In `handleOIDCFlowInitiation`, the `Prompt.LOGIN` + `loginHint` code path was passing `authRequest.id` (raw ID without `oidc_` prefix) to `sendLoginname`. Without the prefix, `completeFlowOrGetUrl` does not recognize the flow as OIDC and falls through to the "Regular flow" path, redirecting to `/signedin` instead of calling `createCallback`. Fixed by using the `requestId` parameter which already carries the `oidc_` prefix. # Additional Changes - Standardized all request ID references in `handleOIDCFlowInitiation` to consistently use the `requestId` parameter instead of reconstructing it with `` `oidc_${authRequest.id}` ``. This eliminates the inconsistency that caused the bug and prevents similar issues in the future. - Removed a redundant `if (authRequest.id)` guard in the LDAP redirect path, since `requestId` is always present as a required parameter. - Added regression tests verifying that `sendLoginname` receives the `requestId` with the `oidc_` prefix in the `Prompt.LOGIN` + `loginHint` code path. |
||
|
|
f32acbfd24 |
fix(login): redirect to loginname instead of empty accounts page when org scope filters all sessions (#12346)
Closes #11914 # Which Problems Are Solved When an OIDC auth request includes an organization scope (`urn:zitadel:iam:org:id:{id}` or `urn:zitadel:iam:org:domain:primary:{domain}`), users with existing browser sessions from *other* organizations were shown an empty Account Selection page with no selectable accounts. The only option was to click "Add another account", adding a confusing and unnecessary extra step. This happened because the `/login` route checked `sessions.length` (all browser sessions, unfiltered) to decide whether to enter the "reuse existing session" branch. Inside that branch, `findValidSession` correctly filtered by organization and returned no match — but the fallback redirected to `/accounts`, which also filters by org and rendered empty. # How the Problems Are Solved Before deciding to redirect to `/accounts`, pre-filter sessions by the requested organization using the same logic already used by the accounts page and `findValidSession`. If no sessions are eligible for the target organization, redirect directly to `/loginname` instead. This applies to both the **default prompt** and **`prompt=select_account`** branches. For `select_account`, this matches the behavior of major OIDC providers like Google and Microsoft, which skip the account chooser and go straight to the login input when there are no sessions to select from. The OIDC spec describes `select_account` as enabling selection "amongst multiple accounts that they might have current sessions for" — showing an empty picker serves no purpose. --------- Co-authored-by: Copilot Autofix powered by AI <[email protected]> |
||
|
Max PeintnerandGitHub
|
782133dbc7 |
fix(login): improve error handling for user registration (#12338)
# Which Problems Are Solved When the registerUser server action failed during registration, all errors from addHumanUser, createSessionWithRetry, and getUserByID propagated as uncaught exceptions to the client component's generic catch block, which always showed the same "Could not register user" message. This made it impossible to distinguish between user creation failures, session creation failures, and user lookup failures — both for end users and in server logs. # How the Problems Are Solved Added .catch() handlers on the three gRPC calls in registerUser that log the actual error and return null, allowing the existing null-check guard clauses to return step-specific error messages (couldNotCreateUser, couldNotCreateSession, userNotFound) through handleServerActionResponse. This gives users more specific feedback and provides server-side logging to narrow down the root cause of flaky signup failures. |
||
|
|
4dc89b499f |
fix(login): allow custom protocols for native apps again (#12332)
# Which Problems Are Solved - Native apps (mobile/desktop) use custom protocol schemes (e.g. `myapp://callback`, `io.zitadel.app://auth`) as OAuth/OIDC redirect URIs. The previous redirect-safety check in the login UI only allowed `http:`/`https:` absolute URLs, so these custom-scheme callbacks were wrongly rejected and native app login flows were broken. - Even for valid external redirects, `router.push()` triggers an RSC prefetch `fetch()` that is blocked by the CSP `connect-src 'self'` directive for non-same-origin URLs, so navigation to external/custom-protocol targets failed. - SAML and OIDC callback URLs returned from the backend were not consistently validated before being used for redirects/POSTs across the various flow entry points. # How the Problems Are Solved - Reworked `isSafeRedirectUri` to use `@braintree/sanitize-url` instead of a strict `http/https`-only allowlist. Custom protocol schemes are now permitted, while dangerous schemes (`javascript:`, `data:`, plus an explicit block of `file:`, `blob:`, `about:`) are still rejected. - Added `isExternalUrl` helper to distinguish internal relative paths (`/...`) from external/custom-protocol targets. - In `handleServerActionResponse`, external/custom-protocol redirects now navigate via `window.location.href` (full navigation) instead of `router.push()`, avoiding the CSP-blocked RSC prefetch. Internal paths continue to use `router.push()`. - Added consistent redirect-URI validation for SAML and OIDC callbacks across all relevant entry points (`oidc.ts`, `saml.ts`, `server/flow-initiation.ts` including the `prompt=none` path, and the SAML `samlData` POST case), blocking unsafe URLs with a clear warning and error response. # Additional Changes - Added `@braintree/sanitize-url` (`^7.1.2`) dependency to `apps/login` (`package.json` / `pnpm-lock.yaml`). - Added unit tests for `isExternalUrl` covering relative paths, absolute HTTP/HTTPS URLs, custom protocol schemes, and protocol-relative URLs. - Annotated the intentional `window.location.href` navigation with a CodeQL suppression comment, documenting that the URL is validated by `isSafeRedirectUri` beforehand. - Minor formatting cleanup in `console` JWT provider component. # Additional Context - This restores behavior that previously worked for native apps but regressed when redirect validation was tightened to `http`/`https` only. --------- Co-authored-by: Max Peintner <[email protected]> |
||
 
|
f9995ee39c |
fix: increase performance of ListUser by login name ignore case (#12350)
# Which Problems Are Solved Login v2 uses the `users.v2.ListUsers`-endpoint to get a user by login name. This query had an inefficient `WHERE`-clause. # How the Problems Are Solved Update the view and use a specific clause for this query. # Additional information Added in https://github.com/zitadel/zitadel/pull/10475 --------- Co-authored-by: Marco A. <[email protected]> Co-authored-by: Livio Spring <[email protected]> |
||
|
Max PeintnerandGitHub
|
3a18cef281 |
fix: prevent double triggering of verification emails (#11995)
# Which Problems Are Solved This fixes a critical bug where initial verification emails (or invite codes) were occasionally sent twice, invalidating the first code and confusing users. Previously, the initial verification email was triggered via a `send=true` URL parameter executing inside a frontend useEffect exactly when the `/verify` page mounted. This was fragile and prone to race conditions caused by component remounts or partial hydration. # How the Problems Are Solved - Removed `send=true` from URL state and ripped out the doSend effect in `VerifyForm.tsx`. - Shifted execution strictly to the Next.js server. The email is now automatically dispatched via await `initialSendVerification(...)` during the POST requests (acting over `sendLoginname`, `register`, `password`, `passkeys`, and `idp`). - The login flow is now idempotent and robust against unintended frontend re-renders. - Refactored `checkEmailVerification()` to be async and updated the associated unit-test coverage (all tests passing). |
||
 
|
14874d6546 |
fix(login): Prevent IDP auto-creation failure when name fields are missing (#11070)
# Which Problems Are Solved
When using IDP auto-creation, the addHuman() call would fail if the IDP
didn't provide required profile fields (givenName or familyName),
resulting in a poor user experience.
# How the Problems Are Solved
Added validation before auto-creation to check if required profile
fields are present. If givenName or familyName is missing, users are now
redirected to the complete-registration page where they can manually
provide the missing information.
- Added profile field validation in CASE 4 (auto-creation) of
processIDPCallback
- Redirect to /idp/{provider}/complete-registration when required fields
are missing
- Pre-fill any available user data in the registration form
---------
Co-authored-by: David Skewis <[email protected]>
Co-authored-by: Florian Forster <[email protected]>
|
||
|
|
2397247925 |
fix(login): improve contrast of IDP processing message (#12309)
# Which Problems Are Solved This improves the contrast of the “Processing authentication...” message shown while Login V2 processes the IDP authentication flow. The previous style used text-gray-600 without a dark-mode variant. This color is hard-coded in the component and is not affected by the branding colors, so users may see low contrast depending on the active theme/background. This PR updates the message text to use a higher-contrast light/dark color pair. --------- Co-authored-by: Max Peintner <[email protected]> Co-authored-by: Max Peintner <[email protected]> |
||
|
Livio SpringandGitHub
|
76fd6d859d |
Merge commit from fork
* fix: ensure external user's email is verified before auto-linking * fix linking |
||
|
Max PeintnerandGitHub
|
239620f112 |
fix(login): center text for generic IDP buttons without icons (#12211)
Closes #12182 # Which Problems Are Solved Generic IDP buttons (OIDC, SAML, LDAP, JWT) used pl-20 to approximate icon offset alignment, but since they have no icon, the text appeared misaligned compared to branded IDPs (Google, Microsoft, Apple). # How the Problems Are Solved Replaced the left-padding hack with centered text so generic IDP names display cleanly within the button. before: <img width="392" height="290" alt="Screenshot 2026-05-28 at 12 03 21" src="https://github.com/user-attachments/assets/64c4e8eb-caec-4742-b61c-e3b0c5093dd7" /> after: <img width="392" height="289" alt="Screenshot 2026-05-28 at 12 07 27" src="https://github.com/user-attachments/assets/d1faf1f4-0aab-475f-8801-15b461e15da4" /> |
||
|
Max PeintnerandGitHub
|
f691851d32 | Merge commit from fork | ||
 Tim MöhlmannandGitHub
|
e94d4c3986 |
feat(crypto): FIPS 140-3 compliant build and runtime checks (#12233)
# Which Problems Are Solved Enable FIPS 140-3 compliant build. # How the Problems Are Solved - Add runtime config validation, if the FIPS flag is enabled fail the application when a non-compliant hasher is used, or throw a warning when a legacy verifier is used - Add a build matrix for FIPS certified build: - Go binary is built with `GOFIPS140=certified` - Login container uses a separate base: [ubi9](https://catalog.redhat.com/en/software/containers/ubi9/ubi/615bcf606feffc5384e8452e) from redhat which provides a FIPS certified OpenSSL (used by NodeJS TLS stack) - Non-FIPS images where already pushed to both Github Container Registry and Google Artifact Repository (GAR). Fips images are only pushed to the GAR. - Tag versions are suffixed `-fips`. So on release the following images will be additionally available: ``` europe-docker.pkg.dev/zitadel-common/zitadel-repo/zitadel-login:vX.Y.Z-fips europe-docker.pkg.dev/zitadel-common/zitadel-repo/zitadel:vX.Y.Z-fips-debug europe-docker.pkg.dev/zitadel-common/zitadel-repo/zitadel:vX.Y.Z-fips ``` # Other changes - Bumb Go toolchain. At least v1.25.10 is required for a GOFIPS140=certified setting. # Additional Context - Closes https://github.com/zitadel/zitadel/issues/4335 - Build [test run](https://github.com/zitadel/zitadel/actions/runs/27253916052) pushing FIPS and non-FIPS images |
||
|
Max PeintnerandGitHub
|
fdafb95a63 |
fix(login): load custom font from branding settings and allow in CSP (#12279)
Closes #11200 # Which Problems Are Solved Custom fonts uploaded via the branding/label policy were not supported. # How the Problems Are Solved - The login now correctly applies the branding settings, based on the organization context - Use the absolute `fontUrl` from the branding API directly in the `@font-face` `src`, matching how logo and icon assets are already loaded via absolute URLs. - Add the Zitadel service URL to the `font-src` CSP directive so the browser permits loading the cross-origin font. # Additional Changes - Updated CSP tests to reflect the new `font-src` behavior. |
||
|
Max PeintnerandGitHub
|
4459a1380c |
fix(login): accept IDP sessions on passkey registration (#12275)
# Which Problems Are Solved The local `isSessionValid` in `passkeys.ts` only checked `password` and `webAuthN` factors, so sessions authenticated via an external IDP (`intent` factor) were treated as invalid. This caused a "You have to authenticate" error when redirecting to `/passkey/set` after IDP login. # How the Problems Are Solved Added `session.factors.intent.verifiedAt` to the validity check, consistent with the canonical `isSessionValid` in `session.ts`. |
||
|
Max PeintnerandGitHub
|
b27fdfc28c |
chore: update dependencies (#12242)
# Which Problems Are Solved Fixes multiple high-severity Dependabot alerts for transitive dependencies (axios, protobufjs, systeminformation, tmp, fast-uri, @babel/plugin-transform-modules-systemjs). # How the Problems Are Solved **Direct dependency updates:** - `@opentelemetry/*` 0.217 → 0.218 in login (new otlp-transformer dropped protobufjs as direct dep) - `posthog-js` 1.374 → 1.380 in console (dropped the OpenTelemetry/protobufjs chain entirely) **pnpm overrides** for remaining transitive deps that can't be updated via their parents (all pulled by the gRPC stack, Cypress, karma, nx, or ajv): - `axios` → ≥1.17.0 (prototype pollution, proxy bypass) - `protobufjs` → ≥7.5.7 / ≥8.0.2 (code injection, prototype pollution, DoS) - `systeminformation` → ≥5.31.6 (command injection) - `tmp` → ≥0.2.6 (path traversal) - `fast-uri` → ≥3.1.2 (path traversal, host confusion) **Benchmark:** refreshed `package-lock.json` to resolve @babel and fast-uri alerts. |
||
|
|
cdc6c43d09 |
fix: update dependencies (#12216)
# Which Problems Are Solved Fixes open vulnerabilities # How the Problems Are Solved Updated npm/js dependencies across console, new login v2, and docs Based on https://github.com/zitadel/zitadel/pull/12164 --------- Co-authored-by: conblem <[email protected]> Co-authored-by: Livio Spring <[email protected]> |
||
|
|
fc6e2a0f05 |
fix(login): retry logic for session creation after registration on NotFound (#12189)
After user registration, the backend projections may not be up to date
yet when the Login UI immediately tries to create a session. This
results in a `QUERY-Dfbg2` ("User could not be found") error even though
the user was created successfully.
This adds retry logic with backoff (500ms/1s/2s, up to 3 attempts)
around `createSessionAndUpdateCookie` in the registration flow. Only
`NotFound` errors are retried — other errors are thrown immediately.
Closes #12173
---------
Co-authored-by: Livio Spring <[email protected]>
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
|
||
|
|
404c23834a |
fix(login): redirect to email verification when forced MFA has no visible factors (#12060)
# Which Problems Are Solved When MFA is enforced with only Email OTP as a second factor, new users hit a dead end on the MFA setup screen. The `ChooseSecondFactorToSetup` component hides Email OTP when `emailVerified` is `false`, and if email verification was skipped earlier in the flow (e.g. `EMAIL_VERIFICATION` env not set to `"true"`), no MFA options are visible and the user cannot proceed. # How the Problems Are Solved In the MFA setup server component (`mfa/set/page.tsx`), before rendering, detect when forced MFA has no visible second factors because all configured factors require verification the user hasn't completed. When Email OTP is configured but the user's email is unverified, redirect to `/verify` with `send=true` so a verification code is sent immediately. After the user verifies their email, the existing flow in `verify.ts` calls `checkMFAFactors` which redirects back to `/mfa/set` — where Email OTP is now visible since `emailVerified` is `true`. The redirect pattern follows the existing precedent in `authenticator/set/page.tsx`. # Additional Changes None # Additional Context - Closes #11536 --------- Co-authored-by: Max Peintner <[email protected]> |
||
|
|
96b3f3dd35 |
fix(login): apply custom request headers from environment variable in proxy (#12144)
Closes #12125 # Which Problems Are Solved The proxy middleware (proxy.ts) did not apply `CUSTOM_REQUEST_HEADERS` to rewritten requests (/.well-known/*, /oauth/*, /oidc/*, etc.). When `ZITADEL_API_URL` points to an internal service name, the Host header on proxied requests remained the internal name instead of the configured public domain, causing Errors.Instance.NotFound. # How the Problems Are Solved The other two outgoing request paths — the connectRPC transport and the security-settings fetch — already applied these headers. This adds the same applyCustomHeaders() call to the proxy path. Co-authored-by: Ramon <[email protected]> |
||
|
|
64737bfedf |
chore: deps update (#12114)
<!-- 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 Outdated depdencies # How the Problems Are Solved This PR mostly just updates our NPM depdencies to the newest feature releases. The UUID package was update to version 14, the changelog only includes changes to the supported node version. # Additional Changes Replace tsx for some scripts in the docs. --------- Co-authored-by: Livio Spring <[email protected]> Co-authored-by: Max Peintner <[email protected]> |
||
|
942c959d09 |
fix(login): resolve localized legal links in signup (#11913)
# Which Problems Are Solved
- Login V2 signup does not resolve the `{{.Lang}}` placeholder in ToS,
Privacy Policy, and help links.
- Clicking those links on the registration page can open URL-encoded
placeholders like `%7B%7B.Lang%7D%7D` instead of the active
language-specific page.
# How the Problems Are Solved
- Adds a small login utility to resolve `{{.Lang}}` placeholders against
the active Login V2 locale.
- Updates the signup legal acceptance component to use the resolved
links before rendering them.
- Applies the same resolution to the optional help link shown alongside
the legal acceptance text.
# Additional Changes
- Adds unit tests for the link placeholder resolver.
- Adds a component test covering localized ToS, Privacy Policy, and help
links on the signup page.
# Additional Context
- Closes #11907
---------
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Max Peintner <[email protected]>
Co-authored-by: Max Peintner <[email protected]>
|
||
|
|
b1c8781516 |
fix(login): lru-cache compatibility, improve session error handling (#12099)
# Which Problems Are Solved - Logo and heading overlap on login pages due to a -mb-4 negative margin on the logo container - The /login route returns a 500 when `listSessions` fails (e.g. stale session cookies), because loadSessions has no error handling. - The proxy logs `"fetch() returned undefined"` because `fetchIframeOrigins` returns undefined, which lru-cache's forceFetch treats as a fetch failure. # How the Problems Are Solved - Remove `-mb-4` from the logo container in DynamicTheme. - Wrap `loadSessions` in a try/catch — failures fall through as empty sessions instead of crashing. - Return `null` instead of `undefined` from `fetchIframeOrigins` so lru-cache caches it normally. --------- Co-authored-by: Livio Spring <[email protected]> Co-authored-by: conblem <[email protected]> |
||
|
Max PeintnerandGitHub
|
de98c6edb8 |
fix(login): ClassifiedConnectError breaking ConnectError instanceof checks (#12022)
# Which Problems Are Solved 1. SSL/TLS handshake failures on Cloud Run (middleware self-loopback) PR #11903 changed the middleware (proxy.ts) to fetch security settings via fetch(origin + "/security") on every request, including non-proxy routes like /login. On Cloud Run, this self-loopback goes through the Google Front End (GFE) load balancer, causing intermittent SSL routines::record layer failure errors that were tenant-consistent. 2. The ClassifiedConnectError introduced in #11926 set this.name = "ClassifiedConnectError", which broke ConnectError's custom Symbol.hasInstance duck-typing check (v.name === "ConnectError"). This caused ConnectError.from() inside the connectRPC transport's abort handler to re-wrap classified errors as new ConnectError instances with Code.Unknown — losing the original gRPC error code and all classification metadata. # How the Problems Are Solved Middleware: eliminate self-loopback fetch: - Replaced the fetch(origin + "/security") self-loopback with a direct fetch to ZITADEL_API_URL using the Connect protocol (POST + JSON), bypassing the load balancer entirely - Security settings are cached in-memory with a 1-hour TTL per instance host - Extracted the fetching/caching logic into src/lib/server/security-settings.ts Removed the now-unused /security API route (src/app/security/route.ts) - CSP headers with iframe origins are now applied to all routes without any loopback Error classification interceptor: fixed - Keep this.name = "ConnectError" in ClassifiedConnectError so the duck-typing Symbol.hasInstance check passes - The branded Symbol.for check via isClassifiedError() still correctly distinguishes the subclass - Remove redundant Object.setPrototypeOf call (the super constructor already handles it via new.target) - Replace remaining instanceof ConnectError checks with isClassifiedError() in setUserPassword and checkSessionAndSetPassword |