MCIAS now acts as an SSO provider for downstream services. Services
redirect users to /sso/authorize, MCIAS handles login (password, TOTP,
or passkey), then redirects back with an authorization code that the
service exchanges for a JWT via POST /v1/sso/token.
- Add SSO client registry to config (client_id, redirect_uri,
service_name, tags) with validation
- Add internal/sso package: authorization code and session stores
using sync.Map with TTL, single-use LoadAndDelete, cleanup goroutines
- Add GET /sso/authorize endpoint (validates client, creates session,
redirects to /login?sso=<nonce>)
- Add POST /v1/sso/token endpoint (exchanges code for JWT with policy
evaluation using client's service_name/tags from config)
- Thread SSO nonce through password→TOTP and WebAuthn login flows
- Update login.html, totp_step.html, and webauthn.js for SSO nonce
passthrough
Security:
- Authorization codes are 256-bit random, single-use, 60-second TTL
- redirect_uri validated as exact match against registered config
- Policy context comes from MCIAS config, not the calling service
- SSO sessions are server-side only; nonce is the sole client-visible value
- WebAuthn SSO returns redirect URL as JSON (not HTTP redirect) for JS compat
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- webauthn.js: read #username value before calling
mciasWebAuthnLogin so non-discoverable keys work when
a username is typed (previously always passed empty string,
forcing discoverable/resident-key flow only)
- handleWebAuthnLoginFinish: evaluate auth:login policy after
credential verification, mirroring the gate in handleLogin;
returns 403 on deny so policy rules apply equally to both
password and passkey authentication paths
Security: policy is checked post-verification so 403 vs 401
distinguishes a policy restriction from a bad credential without
leaking account existence. No service context is sent (WebAuthn
login carries no service_name/tags), so per-service deny rules
don't fire on passkey login; account-level deny rules do.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Fix webauthn.js CSRF token: read HMAC header value from
body hx-headers attribute instead of cookie nonce
- Update profile labels to mention security keys/FIDO2
alongside passkeys
Security: CSRF double-submit was broken for fetch()-based
WebAuthn requests — JS was sending the cookie nonce as the
header value instead of the HMAC. Fixed by reading the
server-rendered header token from the DOM.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Phase 14: Full WebAuthn support for passwordless passkey login and
hardware security key 2FA.
- go-webauthn/webauthn v0.16.1 dependency
- WebAuthnConfig with RPID/RPOrigin/DisplayName validation
- Migration 000009: webauthn_credentials table
- DB CRUD with ownership checks and admin operations
- internal/webauthn adapter: encrypt/decrypt at rest with AES-256-GCM
- REST: register begin/finish, login begin/finish, list, delete
- Web UI: profile enrollment, login passkey button, admin management
- gRPC: ListWebAuthnCredentials, RemoveWebAuthnCredential RPCs
- mciasdb: webauthn list/delete/reset subcommands
- OpenAPI: 6 new endpoints, WebAuthnCredentialInfo schema
- Policy: self-service enrollment rule, admin remove via wildcard
- Tests: DB CRUD, adapter round-trip, interface compliance
- Docs: ARCHITECTURE.md §22, PROJECT_PLAN.md Phase 14
Security: Credential IDs and public keys encrypted at rest with
AES-256-GCM via vault master key. Challenge ceremonies use 128-bit
nonces with 120s TTL in sync.Map. Sign counter validated on each
assertion to detect cloned authenticators. Password re-auth required
for registration (SEC-01 pattern). No credential material in API
responses or logs.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
