Add audit logging to authserver #3919

Context

The authserver is the most security-sensitive component in ToolHive (token issuance, client registration, upstream IDP interaction) yet has zero audit logging. The rest of the codebase has a mature NIST SP 800-53 compliant audit system in pkg/audit/ with structured event types, subjects, targets, and outcomes.

Scope

Define auth event types

New EventType constants in pkg/audit/ (new file authserver_events.go, following mcp_events.go pattern). Failures are NOT separate event types — they are captured via the existing Outcome field (success, failure, error, denied) on each event.

Plus supporting subject keys (oauth_client_id, upstream_issuer, upstream_subject), target keys (session_id, scope, resource, grant_type, revocation_reason), and component constant (toolhive-authserver).

NIST SP 800-53 AU-2 coverage

Future events (oauth_token_introspected, oauth_mtls_auth_attempted, oauth_client_updated/deleted) should be added when their corresponding features land.

Create AuthServerAuditor and wire into handlers

Follow the WorkflowAuditor pattern (pkg/audit/workflow_auditor.go) — a direct auditor that handlers call, rather than generic HTTP middleware. This is preferred because auth operations have rich semantic context (client_id, grant_type, upstream_provider) that HTTP middleware can't capture, and different endpoints need very different audit data.

Wire into each handler:

• AuthorizeHandler: oauth_authorize_request with subjects={client_id}, target={redirect_uri, scope, resource}
• CallbackHandler success: oauth_upstream_auth_complete + oauth_auth_code_issued + optionally oauth_user_created
• CallbackHandler failure: oauth_upstream_auth_complete with outcome=failure/error
• TokenHandler authorization_code: oauth_token_issued with subjects={client_id, user_id, session_id}, target={grant_type, scope}
• TokenHandler refresh_token: oauth_token_refreshed with subjects={client_id, user_id}, target={grant_type}
• TokenHandler failure: relevant event type with outcome=failure
• RegisterClientHandler: oauth_client_registered with subjects={client_id, client_name}
• Upstream token refresh (when implemented): oauth_upstream_token_refreshed with target={upstream_issuer, session_id}
• Session revocation (when implemented): oauth_session_revoked with target={session_id, revocation_reason}

Acceptance criteria

• Auth event type constants defined in pkg/audit/authserver_events.go
• AuthServerAuditor created following WorkflowAuditor pattern
• Auditor injected into Handler via constructor
• Audit events emitted for all handler success and failure paths
• Sensitive data (tokens, PKCE verifiers, authorization codes) NEVER included in audit events
• Source information (client IP, user agent) included in events
• Configuration follows pkg/audit.Config patterns (enable/disable, event type filtering)
• Unit tests verify correct event types, subjects, and outcomes per handler path

Dependencies

• Depends on Add HTTP middleware and logging cleanup to authserver #3918 (HTTP middleware — request IDs needed for audit event correlation)

Delegated access events (add with each feature)

Each feature in #6886 "Authorization server: grants and ID-JAG issuance for delegated agents" and #6887 "Delegated access: subject mapping and user approval" emits its events in the same change:

• oauth_token_exchanged (RFC 8693): subjects = client, user, actor; target = grant type, requested token type, audience
• oauth_session_refresh_token_issued: row ID, kind (session or schedule), session key
• oauth_id_jag_issued: jti, audience, client
• oauth_id_jag_redeemed: jti, source issuer, source subject, local user, approval record ID; outcome denied with a reason (no mapping, no approval, reuse refused, actor not allowed)
• oauth_delegated_approval_created / oauth_delegated_approval_revoked: source = user or administrator
• oauth_token_revoked: single token, or user-wide with the revocation time

Record identifiers only, never token values or assertion contents. The binding key is an identifier, not a secret. Operation and attempt IDs a client passes are recorded as client-reported values.