Add one-click Microsoft 365 login link for non-technical users

[namastex888]

Context

PR #44 shipped Microsoft 365 OAuth in Workit v2.260531.3, but the current happy path is still CLI-local:

wk auth add <email> --services m365 --readonly

That works when a technical operator can run the CLI on the same machine that receives the localhost callback. Bernardo is not technical; the product experience should be a single Telegram/web link he clicks to authenticate with Microsoft.

Problem

A raw Microsoft OAuth URL is not sufficient for Bernardo because PKCE requires the code_verifier and callback state to live somewhere trusted. If we send a URL whose redirect_uri is localhost, Bernardo's browser redirects to his own device, not the agent/Workit environment, so the token cannot be captured or stored.

Desired UX

1. Felipe/Hermes generates a short-lived login link for Bernardo.
2. Bernardo clicks the link in Telegram.
3. Microsoft login opens in the browser.
4. Callback lands on a trusted Workit/Hermes callback endpoint, not localhost.
5. Workit exchanges the code with PKCE and stores the refresh token under the m365 client namespace.
6. Bernardo sees a success page: "Microsoft 365 connected read-only".
7. No CLI, no copied auth code, no technical instructions.

Requirements

• Read-only only: User.Read, Mail.Read, Calendars.Read, plus offline_access for refresh.
• No write scopes.
• Short-lived state, ideally 10 minutes.
• One-time-use state/code verifier.
• Token storage remains separate under Workit client m365 / provider microsoft_graph.
• Audit event for created link, successful callback, failed callback, expired state.
• Do not log raw tokens or email body/content.
• Fail closed if state is missing/expired/reused, client id missing, tenant mismatch, or Graph /me email does not match intended account.

Proposed implementation

Add a lightweight hosted login broker, either as:

Option A — Workit command + Hermes callback bridge

• wk auth m365 broker start or equivalent local service started by Hermes/KHAW.
• Hermes exposes a public HTTPS callback URL or reverse tunnel.
• Generated login link embeds signed opaque state only.

Option B — Workit hosted mini callback service

• A small HTTP service in Workit that owns the state store and PKCE verifier.
• CLI/Hermes calls an endpoint to create the login session.
• Callback endpoint exchanges token and stores credentials.

Acceptance criteria

• wk can generate a Bernardo-safe one-click URL without exposing secrets.
• Clicking the URL completes auth without CLI interaction from the user.
• Tests prove state is one-time, expires, and is bound to expected email.
• Tests prove no write scopes appear in generated OAuth URL.
• Tests prove callbacks with mismatched email fail closed.
• Dogfood with fake Client ID validates URL structure; real app config validates full login.

[namastex888]

Enterprise correction: callback/broker boundary

Felipe pointed out the important correction: Workit already has an existing hosted OAuth relay default in code:

• internal/config/defaults.go: DefaultCallbackServer = "https://auth.automagik.dev"
• Google headless flow derives redirect as https://auth.automagik.dev/callback
• Current Vercel handler is Google-specific (vercel/api/callback.ts) and exchanges against https://oauth2.googleapis.com/token

So the mistake is treating https://login.workit.ai/m365/callback as the canonical default. For the public Workit/Automagik product, the equivalent domain is already conceptually auth.automagik.dev.

For Hapvida enterprise, however, we should not use Automagik's public OAuth relay as the production callback/token broker for Bernardo/Hapvida M365.

Correct enterprise target

Deploy a separate Hapvida-owned Workit M365 auth broker inside the OCI HV environment.

Suggested shape:

• Domain: Hapvida-controlled, e.g. https://workit-auth.<hapvida-domain> or an approved OCI HV ingress hostname.
• Redirect URI registered in Entra: https://<hapvida-owned-auth-domain>/m365/callback
• Start URL for Bernardo: https://<hapvida-owned-auth-domain>/m365/start/<opaque-state>
• Microsoft app registration: separate Hapvida app, single-tenant, Graph delegated read-only scopes only.

Why separate from auth.automagik.dev

• Corporate trust/governance: tokens and callback state remain inside Hapvida-controlled infra.
• Tenant-specific Entra app: admin consent, audit, and app ownership sit with Hapvida.
• Fail-closed enterprise policy: no cross-customer/public relay for executive M365 refresh tokens.
• OCI HV deployment gives InfoSec a clean boundary.

Reuse from existing code

We can reuse the existing Workit auth-server/relay pattern, but need M365-specific endpoints:

• POST /m365/sessions or internal CLI equivalent: create state + PKCE verifier + expected email + TTL.
• GET /m365/start/:state: redirects to Microsoft authorize URL.
• GET /m365/callback: validates state, exchanges code with Microsoft using PKCE verifier, fetches Graph /me, verifies expected email, stores refresh token.
• GET /m365/status/:state or delivery callback: lets Hermes know login completed.

Update acceptance criteria

• Use existing auth.automagik.dev pattern as reference, not as Hapvida production target.
• Hapvida one-click broker must be deployable inside OCI HV.
• The Entra redirect URI must point to the OCI HV broker, not login.workit.ai unless that domain is explicitly owned/approved for Hapvida.
• Public Automagik relay can remain for generic Google/public Workit flows; Hapvida M365 uses isolated enterprise broker.