token auth infrastructure is complete but not usable end-to-end

[RichardAtCT]

Description

ENABLE_TOKEN_AUTH=true activates a TokenAuthProvider that is fully implemented but cannot actually authenticate users through the Telegram bot flow. Three gaps prevent it from working in practice.

Problems

1. No mechanism for users to submit tokens

There is no command (e.g., /auth <token>) or other UX for a Telegram user to present a token. The token generation method (TokenAuthProvider.generate_token()) exists but is never called from any handler.

2. Middleware never passes credentials to the auth manager

The auth middleware (src/bot/middleware/auth.py:65) calls:

authentication_successful = await auth_manager.authenticate_user(user_id)

No credentials dict is passed, so TokenAuthProvider.authenticate() always receives {}, finds no "token" key, and returns False.

3. Token storage is in-memory only

src/main.py initializes InMemoryTokenStorage() with a # TODO: Use database storage comment. Tokens are lost on every restart. The SQLite schema (user_tokens table in src/storage/database.py:103-113) and data model (UserTokenModel in src/storage/models.py:277-314) already exist but are unused.

What already works

• TokenAuthProvider — token generation, SHA256 hashing, verification, revocation (src/security/auth.py:142-213)
• InMemoryTokenStorage — functional in-memory implementation (src/security/auth.py:111-140)
• Config validation — cross-field check requiring AUTH_TOKEN_SECRET when enabled (src/config/settings.py:351-354)
• Feature flag — token_auth_enabled property in FeatureFlags (src/config/features.py:42-47)
• DB schema — user_tokens table with token_hash, expires_at, last_used, is_active columns
• Tests — comprehensive coverage in tests/unit/test_security/test_auth.py

Suggested fix

1. Add an /auth <token> command that passes {"token": token} as credentials to auth_manager.authenticate_user(user_id, credentials)
2. Add a way for admins to generate tokens (e.g., /generate_token <user_id> or a CLI utility)
3. Implement SqliteTokenStorage backed by the existing user_tokens table
4. Wire SqliteTokenStorage into src/main.py in place of InMemoryTokenStorage

[RichardAtCT]

Token auth infrastructure remains complete but not wired end-to-end. The three gaps identified are still present:

1. No /auth command for users to submit tokens
2. Auth middleware doesn't pass credentials to TokenAuthProvider
3. InMemoryTokenStorage needs replacement with SqliteTokenStorage (DB schema already exists in user_tokens table)

This is a good candidate for a contributor — the building blocks (TokenAuthProvider, DB schema, feature flags) are all in place. Just needs the plumbing.

[IliyaBrook]

Done! #190 A few small deviations from a strict reading of the spec:

1. Rolling token expiration. expires_at slides forward to now + 30 days on every successful auth instead of a hard cutoff — only 30 days of real inactivity expires the token.

2. Silent re-auth inside the 30-day window. The original design forces users to resend /auth <token> every time the 24h session lapses. In Telegram this felt redundant — user_id is already platform-verified on every message, so re-presenting the raw token daily adds friction without real security. Now, if the caller has a non-expired token on record, empty credentials are accepted and the token refreshes. A wrong raw token is still rejected.

3. Added a parallel, simpler auth path: persistent allowlist. /auth add <user_id> / /auth remove <user_id>, no TTL, backed by the existing users.is_allowed column. The token dance makes sense for cross-channel handoff; for trusted users it's overkill.