Add OIDC sign-in and user-provided credentials to the hosted widget

[aditya-damerla128]

Follow-up to #260, which provides the hosted-widget delivery foundation. This issue adds authentication behavior after #260 lands; it does not change the delivery work in #260.

Once the server is configured with Google, Apple, and email-OTP providers, the hosted widget supports these credential paths:

1. Host-configured agent key or parent key

If the embedding page supplies an agnt_key-... agent key or ozw_... parent key, retain the existing direct-key flow. Do not show a login modal.

2. OIDC sign-in when the page supplies no key

If no host key is configured, opening the widget presents sign-in with Google, Apple, or email OTP. Successful sign-in authorizes that user to use the chat for the current authenticated session. This issue does not add chat-history or memory persistence.

3. User-provided key

The same modal offers entry of the user’s own agent key or parent key. A key can be used for the current session without saving. Remembering it in the browser is an explicit opt-in, with a warning that browser-stored credentials are appropriate only on a trusted personal device. Provide a clear “forget key / sign out” control.

This is additive: it supplies a fallback only for keyless embeds and does not remove, alter, or prompt over the existing host-configured key flows. Model-selection and agent model-locking behavior are out of scope and will be tracked separately.

[aditya-damerla128]

Clarification for #263:

• This is additive. A host-configured agent key or parent key continues to use the existing direct-key flow, without a login prompt.
• Only a keyless embed opens the authentication modal.
• The modal supports Google, Apple, email OTP, and optional entry of a user-owned agent key or parent key.
• OIDC sign-in authorizes use of chat for the authenticated session only. Chat-history and memory persistence are not part of this issue.
• A user-provided key defaults to use for the current session. Persisting it in the browser requires explicit opt-in, a trusted-device warning, and a clear forget/sign-out control.
• Model-selection and agent model-locking behavior are separate follow-up work.

[aditya-damerla128]

A proof of concept of how this would work is

In this widget, there would be a login button which has the following pop up

along wiht another option clearly labelled with the risks, to get your own agent/parent key

[aditya-damerla128]

Handover — current state of #263

Where the work lives: PR #275 (feat/issue-263-widget-auth), draft, based on dev.

What works today

All three credential paths from the issue are built and verified end to end against a local server:

• Host-configured key — unchanged. No modal, existing direct-key flow.
• Google sign-in — OAuth 2.0 authorization code with PKCE (S256), state for CSRF, nonce for replay, ID token verified against Google's JWKS for issuer, audience, nonce and email_verified. Runs in a popup, because Google will not render consent inside an iframe.
• Email one-time code — six digits, 10-minute expiry, 5 attempts, 3 codes per address per 15 minutes.
• User-provided key — session-only by default, remembering it is explicit opt-in with a trusted-device warning, and there's a forget/sign-out control.

A successful sign-in mints a sess_ token. One onRequest hook in server.ts swaps it for that user's own parent key, so every existing key-authenticated route works unchanged and usage is attributed to the person rather than a shared key.

Things the next person has to do before this can ship

1. Replace the Google OAuth credentials. The GOOGLE_CLIENT_ID / GOOGLE_CLIENT_SECRET used in development belong to a personal Google Cloud project and will disappear with the account. An org-owned OAuth client is needed, with PUBLIC_BASE_URL + /auth/oidc/google/callback registered under Authorized redirect URIs — not Authorized JavaScript origins, which rejects any URL with a path. Without this, Google sign-in silently stops working on any deployed server.

2. Verify SMTP from inside the DC. The relay to use:

SMTP_URL=smtp://relay.cluster.mieweb.org:25
SMTP_FROM=no-reply@os.mieweb.org

No credentials, no TLS, and STARTTLS explicitly unsupported — the transport disables opportunistic upgrades for that reason. The sender must be an @os.mieweb.org address. It only answers from inside the Phoenix DC, so it has never been exercised against the real relay; sending was verified locally against a stand-in SMTP server. First real send happens on the dev container.

With SMTP_URL unset the code is logged instead, which is how local development works and should stay that way.

3. Decide how sign-in provisions accounts. Currently any address that signs in gets an active account and its own API key created on the spot — ensureManagerUserProvisioned was written for the manager console, where MIE's auth proxy had already authenticated the person. Widget sign-in reuses it with no proxy in front. Three options: leave it open, require pre-provisioned users, or allow-list by domain. This should be settled before the demo page is publicly reachable.

4. Apple sign-in is not built. Google-only was a deliberate first step. Apple differs enough to be real work: the client secret is a JWT that expires and must be regenerated, the response mode is form_post rather than a query redirect, and name and email arrive only on the very first authorization.

Still open, lower priority

• The integration guide needs both embed modes side by side — configure an agent key, or let users sign in. It currently documents only the first.
• A mieweb/ui playground ticket is planned but not filed: the chat component's Storybook controls should be able to point at a real dev or prod API, and the README should state that production embedding is the loader script from the API origin, not importing the component.

Testing it locally

cd <worktree> && ./scripts/start.sh

Then http://localhost:8080 → "Try the sign-in demo". Ollama or the gateway needs to be up for chat to answer.

To exercise the mail path without a relay, point SMTP_URL at any local SMTP listener on 127.0.0.1 — with a sender configured, the code stops appearing in the logs and AUTH_DEV_ECHO_OTP is ignored, which is the production behavior.