Expand auth crate to cover Axon, Labby, and Cortex auth capabilities

[jmagar]

Goal

Extract and update the shared auth crate so generated Rust MCP servers can support the auth patterns currently used by jmagar/axon, jmagar/labby, jmagar/cortex, and rmcp-template without copying product-specific policy into the shared layer.

This issue intentionally rolls in the standalone-auth extraction scope from #66. Treat this as the canonical implementation issue for the shared auth crate.

Current findings

• Lab's labby-auth is the strongest donor because it already has feature boundaries for core auth, Axum HTTP, and upstream OAuth/RMCP support.
• Axon's axon-authz shows the desired separation: product-specific scopes and policy should live outside the shared auth crate.
• Cortex adds operational hardening worth porting: typed config translation, admin/read static-token policy, trusted gateway mode, and file-permission hardening.
• rmcp-template already has local auth behavior and tests that should migrate to the shared crate through a thin template-local policy wrapper.

Locked decisions

• Shared auth mechanics belong in the new crate; product scopes, env prefixes, route policy, and service-specific authorization rules belong in thin per-server wrappers.
• The crate must be usable without Axum unless an HTTP/Axum feature is enabled.
• The crate must not depend on gateway, Code Mode, traces, OpenAPI, or product runtime crates.
• Preserve loopback development ergonomics.
• Preserve trusted gateway/no-auth deployment modes, but make the trust boundary explicit.
• OAuth metadata must reflect enabled routes and registration behavior accurately.

Requirements

• Inventory auth capabilities in jmagar/axon, jmagar/labby, and jmagar/cortex.
• Support static bearer tokens, trusted gateway/no-auth deployment modes, OAuth/JWT flows, upstream OAuth/RMCP support, and scope enforcement used across those services.
• Provide feature-gated core, HTTP/Axum, Google OAuth, and upstream OAuth/RMCP support.
• Provide adapters or migration guidance for existing rmcp-family servers.
• Replace Lab-branded defaults with host-supplied configuration.
• Keep token, route, metadata, and storage behavior testable without live credentials.

Known blockers to fix

• TOKEN_ENCRYPTION_KEY is parsed and SQLite supports keyed open, but AuthState::new still opens SQLite without passing the key.
• Configurable login/callback paths exist but route mounting hardcodes /auth/login and /auth/google/callback.
• Metadata advertises registration_endpoint even when dynamic registration is disabled.
• Lab-branded defaults remain in shared auth surfaces.
• Cortex docs/code around /register and dynamic registration should be reconciled before treating Cortex behavior as precedent.

Acceptance criteria

• New/extracted auth crate has feature-gated core, HTTP/Axum, Google OAuth, and upstream OAuth/RMCP support.
• No product-specific scope names, env prefixes, branded defaults, or route policies are baked into the shared crate.
• The shared auth crate can replace the service-local auth behavior needed by Axon, Labby, Cortex, and rmcp-template.
• rmcp-template consumes the crate through a thin template-local policy wrapper.
• Generated template services can opt into supported auth modes through documented configuration.
• Token encryption configuration is actually wired into the storage layer.
• Route mounting honors configured login/callback paths.
• OAuth metadata matches enabled routes and registration behavior.
• Tests cover bearer-only, OAuth, static-token-with-OAuth policy, trusted gateway mode, route metadata, token validation, scope checks, expected failure responses, encryption key wiring, and file permission hardening where applicable.
• Existing rmcp-template auth tests continue to pass or are migrated to the new crate.

Sources

• /home/jmagar/workspace/lab/crates/labby-auth/Cargo.toml:15 — current feature split.
• /home/jmagar/workspace/lab/crates/labby-auth/src/config.rs:274 — parameterized AuthConfigBuilder.
• /home/jmagar/workspace/lab/crates/labby-auth/src/state.rs:115 — auth state opens SQLite store.
• /home/jmagar/workspace/rmcp-template/crates/rtemplate-auth/src/config.rs:386 — token encryption key parsing.
• /home/jmagar/workspace/rmcp-template/crates/rtemplate-auth/src/sqlite.rs:49 — keyed SQLite open support.
• /home/jmagar/workspace/rmcp-template/crates/rtemplate-auth/src/routes.rs:15 — hardcoded route mounting.
• /home/jmagar/workspace/rmcp-template/crates/rtemplate-auth/src/metadata.rs:6 — registration endpoint metadata.
• /home/jmagar/workspace/axon/crates/axon-authz/src/lib.rs:9 — thin product authz wrapper.
• /home/jmagar/workspace/cortex/src/runtime.rs:1260 — Cortex auth policy construction.

Supersedes

• Extract standalone auth crate for Rust MCP servers #66 can be closed as folded into this issue once this body is accepted.

Implementation phases

1. Inventory donor auth behavior.

   • Compare Labby, Axon, Cortex, and rmcp-template auth models, route mounting, metadata, storage, token validation, and scope checks.
   • Separate shared mechanics from product policy.

2. Define shared crate API.

   • Design core config/state/token/scope abstractions without Axum dependencies.
   • Gate HTTP/Axum, Google OAuth, and upstream OAuth/RMCP behavior behind features.
   • Define product wrapper boundaries for scope names, env prefixes, route policy, and branding.

3. Port storage and metadata behavior.

   • Wire token encryption into SQLite open paths.
   • Fix configurable login/callback route mounting.
   • Fix OAuth metadata and registration endpoint behavior.
   • Add file-permission hardening where applicable.

4. Integrate rmcp-template.

   • Replace template-local auth plumbing with a thin policy wrapper over the shared crate.
   • Preserve loopback development, bearer-token mode, trusted gateway mode, and OAuth behavior.

5. Add migration docs and tests.

   • Add unit/integration tests for auth policies and failure responses.
   • Document migration path for rmcp-family servers.

Local files likely touched

• crates/rtemplate-auth/*
• crates/rtemplate-runtime/src/server.rs
• crates/rmcp-template/src/main.rs
• crates/rmcp-template/src/routes.rs
• crates/rtemplate-contracts/src/config.rs
• auth-related tests under crates/*/tests or crate-local *_tests.rs
• generated docs/env registry docs
• release/components.toml if the shared auth crate becomes independently versioned

Risks

• Mixing product-specific scopes/policies into the shared crate.
• Breaking loopback/no-auth developer mode while tightening production auth.
• Advertising OAuth metadata routes that are not actually enabled.
• Opening encrypted token stores without the configured key.
• Pulling Axum/OAuth dependencies into consumers that only need bearer-token validation.