jobtrackingapp/docs/verification/sec-004-microsoft-identity.md

SEC-004 canonical Microsoft identity verification

Date: 2026-08-02

Status: IMPLEMENTED — NOT VERIFIED. Repository implementation, synthetic controller tests, frontend component tests, build, migration SQL and disposable SQLite upgrade checks pass. Real Microsoft, browser, SMTP, MariaDB execution and production legacy inventory remain blocked.

Implemented trust path

• Microsoft account ownership is the normalized GUID pair (MicrosoftTenantId, MicrosoftObjectId) with a unique composite database index.
• Exchange and conflict lookup use only that pair. MicrosoftSubject is no longer written and provider email is metadata only; a matching local email returns a safe conflict instead of a link.
• New Microsoft registration stores the pair immediately, leaves application email unconfirmed, and obeys the verification-required 202/no-session gate.
• Explicit link requires the authenticated local user's current password. Link and unlink revoke all sessions/trusted devices; passwordless unlink is refused as a last-credential guard.
• Legacy fields remain null-canonical evidence. A single eligible candidate receives a purpose-bound proof at its confirmed application email. Confirmation requires that proof plus a fresh Microsoft token for the exact same (tid, oid) pair. Multiple or unconfirmed candidates require operator-assisted recovery.
• Frontend MSAL authority uses the same AUTH_MICROSOFT_TENANT value passed at build time.

Evidence

• Focused auth controller tests: 34/34 passed.
• Full backend suite: 507/507 passed.
• Full frontend suite: 44 suites, 152/152 passed; production build passed.
• SQLite migration SQL uses two nullable TEXT columns and a unique composite index.
• MariaDB migration SQL uses two nullable varchar(36) columns and the same unique index.
• Disposable SQLite legacy rehearsal:
  • two rows with duplicate legacy subject/email values remained unchanged and null-canonical;
  • migration applied without backfill;
  • first canonical pair assignment succeeded;
  • duplicate pair assignment failed with SQLite unique-constraint exit 19.
• Production Compose interpolation includes the same tenant mode in backend configuration and the frontend build argument.

Blocked checks and residual risk

• No real Microsoft token/account was used. Issuer/tenant/signature behavior is covered by the SEC-003 signed-token tests; exchange/link/recovery use mocked tenant-qualified principals.
• The existing browser policy blocker was not retried. No browser workflow, popup, accessibility, mobile or screenshot claim is made.
• No SMTP sink was available, so the complete emailed recovery link was not exercised end to end.
• MariaDB SQL generation passed, but no disposable MariaDB execution environment was available.
• Production legacy counts and collision groups are unknown. Microsoft production enablement must remain gated until the counts-only inventory in deploy/README.md and migration/version-skew checks pass.
• Legacy rows with multiple candidates or unavailable/unconfirmed app email deliberately require operator verification; no automated merge is attempted.

Rollback

Disable Microsoft sign-in by clearing its client ID, roll back application binaries, and retain the additive columns and legacy evidence. Do not restore subject-only or email auto-linking. The migration Down is appropriate only before canonical pair data is relied upon.