Improvement: Expose authentication management options (password, 2FA, passkeys) in account settings

[geneticallymodifiedfoodforthought]

Summary

Users currently have no in-app way to manage authentication settings such as password changes, two-factor authentication (2FA), or passkeys. These options are not surfaced in the account settings UI at /account.

Current Behavior

• No password change option in account settings
• No 2FA enrollment or management
• No passkey registration
• Users must rely on the "Forgot password" flow on the login screen for password resets

Expected Behavior

Account settings should provide a dedicated Security section where users can:

• Change their password (for password-based accounts)
• Enroll in and manage two-factor authentication (TOTP, SMS, or hardware key)
• Register and manage passkeys (WebAuthn / FIDO2)
• View and revoke active sessions

Notes

• AuthKit (WorkOS) supports passkeys and 2FA — this may primarily be a UI/surface issue rather than a backend capability gap
• SSO users (Google, GitHub, etc.) would reasonably see a reduced set of options scoped to what's manageable on the AAO side
• Priority: low / nice-to-have

References

• WorkOS AuthKit docs: https://workos.com/docs/user-management

[bokelley]

Triage

Thanks for filing!

Classification: Feature request
Bucket(s): admin-tool, website, security-sensitive
Status: ready-for-human

What the experts said:

• security-reviewer: Always Flag — custom auth-management UI has multiple blockers: server-authoritative method detection before any mutation (the account-linking.ts pattern is the right model), WebAuthn ceremony must delegate to WorkOS hosted flow (custom challenge logic voids WebAuthn's security property), and the account-linking × 2FA enrollment interaction needs explicit design. Existing 60s cross-instance session-revocation propagation window (in-process cache TTL in auth.ts) must be documented in the UI. No TEE/adcp-go exposure.
• internal-tools-strategist: Real UX gap but scope is overbuilt as described — WorkOS AuthKit's hosted user-settings portal already handles password change, 2FA, and passkeys; a "Manage security settings" redirect link covers ~90% of the value at near-zero implementation cost and no new security surface. Session revocation is the only item requiring new server routes, and it's timing-conflicted with the active WorkOS OAuth work stream (PRs feat(server): accept OAuth user JWTs at /api/* #2962, fix(registry): accept WorkOS OIDC access tokens on operator & agents #2956, fix(registry): pick JWKS per-token from iss claim, not WORKOS_CLIENT_ID #2960). No org-member demand signal.

My take: The gap is real (password-based accounts have no in-product credential-management path), but the custom UI path carries security blockers and is poorly timed against the in-flight WorkOS OAuth work. @bokelley, your call: Option A — link to WorkOS hosted portal (ships now, low risk, no new security surface) or Option B — custom embedded Security section (needs security sign-off + should wait for the #2962/#2956/#2960 stream to land first).

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01TgMUkYdT2X77mEaPHdu9zB

---

Generated by Claude Code