Current status

The main Kulinaryos sign-in page now offers two paths: email and password, or Sign in with Google. The Google button opens Google's account chooser directly, passes through Food Process's ZITADEL, and returns to an existing Kulinaryos account with an authenticated session. Recovery of the current password sends a transactional email through Brevo. We validated the change in UAT before promoting it to production.

This record closes the login consolidation work that followed several authentication problems and points of friction. Social sign-in required an unclear intermediate page, existing accounts needed a safe linking rule, and password recovery links did not always open the new-password form. Product authorization and licenses remain the responsibility of CRM and ADM; connecting those decisions to identity is a later phase.

How sign-in works today

  • Existing password: the Kulinaryos form sends credentials to the Go API, which authenticates the current product account. Users did not have to change their passwords to gain the Google option.
  • Recovery: the Go API creates a single-use reset request and sends it through Brevo, using info@kulinaryos.com as the sender. The link opens the new-password form in the app; after the change, the user can start a new session with that password.
  • Google: the frontend starts OIDC at the Go API with provider=google. The API redirects through ZITADEL, which remains the identity issuer. The flow retains PKCE, state, and nonce; the browser reaches Google's account chooser and returns through the API callback. The button appears only when the API reports that the provider is active.
  • Environments: UAT and production have separate OIDC clients, callbacks, credentials, and product databases. They share the central ZITADEL instance and identity directory. Restricted access to UAT applies to either sign-in method.

Self-hosted ZITADEL, backed by PostgreSQL in the Food Process cluster, provides the central identity layer and Google federation. Legacy product passwords and their recovery are still handled by the Go API and Brevo. This boundary matters: putting ZITADEL in the Google flow does not mean every existing password has already migrated to it.

Automatic account linking without approval queues

When Google confirms a verified Gmail address matching an existing account's email, the API automatically links the central identity to that account. The user enters the account they already had, without a duplicate registration or an individual manager approval. If the addresses differ, the person can prove ownership of the existing account with their password and complete linking themselves. A similar name or address is not enough to authorize automatic linking.

This rule keeps authentication separate from authorization. In the ecosystem design, CRM is the authority for registration, licenses, and usage permissions; choosing Google or password does not create a license or expand privileges. UAT's restricted-access policy also applies equally to both methods.

What changed on 3 October

We first promoted the API's automatic linking for existing accounts and the public interface in six languages, including sign-in and recovery. We then upgraded ZITADEL to v4.19.2 after checking an off-host backup and an isolated database restore. The previous version was affected by security advisory GHSA-g8gj-gq47-xgf4. This update preceded the direct Google entry point in production.

Next, we deployed the Go API that starts OIDC directly with the Google provider and the frontend with the Sign in with Google button. The generic “Food Process” button left the main sign-in page. Each promotion used an immutable image through GitOps; the API was checked before changing the app image.

Evidence of operation

  • In UAT, a real Google sign-in linked an identity to an already registered account and reached the dashboard without creating another account. We also completed a Brevo recovery, signed out, and signed back in with the new password.
  • In production, the published API reported Google as active; redirects traversed API → ZITADEL → Google. In the published interface, the button opened Google's account chooser and returned an existing account to the authenticated dashboard.
  • Password sign-in, sign-out, and email recovery had already been exercised in production during this consolidation. Their routes remain available alongside the new button.
  • After the promotion, the API, frontend, and identity service were ready, and ArgoCD returned to Synced/Healthy. A pending certificate for prova.kulinaryos.com, which belongs to a separate public trial, was resolved by publishing its DNS record. That hostname is outside the sign-in flow.

Next steps

This release gives existing users a working baseline. The next engineering session will harden identity policies: administrator MFA, session and recovery review, abuse limits, observability, and alerts. We will then connect authentication to CRM's registration, authorization, and license decisions. Brevo remains Food Process's transactional email service.

Change record