Investigating Kulinaryos authentication

The access diagnosis is ongoing. The central identity plan with Go and ZITADEL includes username and password or Google sign-in, with safe account linking.

Summary

We are investigating a reported problem with Kulinaryos authentication. This is a diagnostic update, not a root-cause finding or a recovery announcement. We still need to confirm which flows and users were affected, when the problem started, and whether it continues.

What we have verified

Production code and configuration show that the Go Kulinaryos API already handles registration, password verification, and token issuance. The interfaces do not, however, share a single login session: the web application uses a protected session cookie, while CRM and Command Center maintain their own browser-side flows and tokens. This difference creates more paths to investigate, but does not by itself establish the cause of the reported problem.

In a public check on September 29, the authentication pages responded and the API health endpoints were available. This establishes reachability at that point in time, not a successful real login. Without an authenticated test and correlated logs, we cannot state the failure rate, incident scope, or cause.

Investigation in progress

Reproduce the error in each interface and record the time, response, and request identifier.
Correlate edge, API, and session-store logs with login, refresh, and logout attempts.
Examine credentials, cookies, token refresh, and permissions after authentication separately.
Publish the incident window, impact, confirmed cause, and recovery once the evidence supports them.

Where we are going

Our goal is a central login for Food Process products, with self-hosted ZITADEL in the Food Process cluster as the identity provider and a Go backend as the integration layer for applications. The planned flow uses OpenID Connect Authorization Code with PKCE. ZITADEL authenticates the person and provides identity; the Go backend validates that identity, establishes the application session, and enforces Kulinaryos organization and permission rules. Migration should preserve accounts and access through controlled, product-by-product tests and a rollback plan.

Two ways to sign in, one identity

The central login should offer username and password managed by ZITADEL and Google sign-in through an external provider configured in ZITADEL. The Go backend will not receive the Google password or need to store a second password for the same user.

A local identifier can differ from the Google account email: for example, ana@empresa.com for local access and ana@gmail.com at Google. Username and email are sign-in and contact attributes, not the person's definitive key. Linking to an existing account will require proof of control of that account and an explicit confirmation. Matching or differing emails must not automatically merge accounts or grant access to organizations because the text happens to match. After linking, both methods should resolve to the same ZITADEL identity and the same internal PostgreSQL user.

Before launch, we will verify how the selected ZITADEL version presents both options for already linked accounts, as well as cases involving different emails, account recovery, and unlinking.

ZITADEL matters to the ecosystem because it brings identity policies, multifactor authentication, and modern sign-in methods into a shared service. New products can use the same protocol, and security changes can be applied consistently. A unified login experience also requires each application's integration and a common session policy; installing the provider alone does not deliver it.

Running this service in our own cluster makes us directly responsible for availability, upgrades, key protection, observability, and tested backups. These are requirements of the migration project, not automatic outcomes of choosing ZITADEL.

Security emails with Brevo

We have chosen Brevo for Food Process transactional email, including password recovery links. In the current model, the Go API owns recovery links and is prepared to send them over encrypted SMTP once delivery is activated. As each account moves to central identity, ZITADEL must send its own verification and recovery emails through Brevo: a password managed by ZITADEL must not be reset directly in the product database.

The network check found SMTP ports 587 and 465 unavailable from the Droplet; Brevo's port 2525 accepted a STARTTLS connection with a valid certificate. Brevo documents this alternative. We published authentication records in the authoritative DNS zone, and Brevo marked kulinaryos.com authenticated and info@kulinaryos.com verified as a sender. An SMTP test from the production host appears in Brevo's transactional log as Sent and Delivered. The credential stays outside the code, in the operational vault and backend Secret. The provider's delivery event does not yet prove inbox placement or the API's recovery flow; we will test the link and its single-use behavior after promoting the image.

Current status

The Go backend foundation and identity manifests have been merged into their repositories. Promotion of the new API image has been merged, but production still runs the previous image: ArgoCD has the root application and cannot read the private repository without a dedicated read credential. ZITADEL has not been installed, and users remain on the current login flow. Its dedicated database now uses private access with verified TLS; the first backup was copied off host, checked and restored in isolation. DNS for the auth.kulinaryos.com issuer points to the production ingress. The identity manifest remains outside automatic reconciliation until its dependencies are validated. The API's real password-reset email and Google login are not yet validated.

The investigation remains open. A code merge does not mean access has recovered. This update does not establish a root cause, quantified impact, or confirmed recovery time. We will update this record when those facts are verified.