Skip to main content

Authentication and Access Control

Confirmed Authentication Mechanisms​

Aventora-Assistant​

  • Primary API authentication is API-key based using FastAPI dependencies:
    • Aventora-Assistant/auth/middleware.py
  • API key records are stored as SHA-256 hashes (not plaintext API keys):
    • Aventora-Assistant/db/api_key_manager.py
  • Permission-based access checks map endpoint patterns to permissions:
    • Aventora-Assistant/auth/middleware.py (ENDPOINT_PERMISSIONS, require_* dependencies)
  • Hybrid super-admin flow exists: Hub can accept domain-chatbot validated JWT for selected management routes:
    • require_api_key_management_or_super_admin_jwt() in Aventora-Assistant/auth/middleware.py

domain-chatbot​

  • JWT access token issuance/validation and refresh token handling:
    • domain-chatbot/LLM_full/auth/router.py
    • domain-chatbot/LLM_full/auth/service.py
  • Password hashing/checking uses bcrypt:
    • user registration and update paths in domain-chatbot/LLM_full/db_operations.py
  • Domain API keys and temporary access tokens implemented:
    • domain-chatbot/LLM_full/auth/router.py
    • domain-chatbot/LLM_full/db_operations.py

Authorization Model (Confirmed)​

  • Hub authorization is permission-scoped by API key capability (account_access, call_management, billing_access, etc.).
  • domain-chatbot provides role checks (is_admin, domain ownership/context checks) in auth dependencies.
  • Many protected routes are dependency-guarded at endpoint level rather than global middleware.

Session and Token Behavior (Confirmed)​

  • domain-chatbot supports temporary access tokens in DB and token validation endpoints.
  • Hub can fetch/validate JWT context from domain-chatbot for privileged workflows.
  • OAuth tokens for Google/Microsoft are stored in Hub user records for calendar integration:
    • Aventora-Assistant/db/user_manager.py

Assumptions (Explicit)​

  • No claim is made that enterprise SSO, enforced MFA, or centralized IAM policy is globally required across all production paths.
  • Any reverse-proxy-level auth controls (if present) are infrastructure-dependent and not verifiable from code.

Gaps / Risks​

  1. Inconsistent auth model across systems (API key + JWT + temporary tokens) increases policy drift risk.
  2. No global auth middleware baseline; protection is route-by-route and may be error-prone over time.
  3. OAuth state/nonce anti-CSRF hardening is not clearly enforced in Hub OAuth generation/exchange path:
    • Aventora-Assistant/db/user_manager.py includes optional state forwarding but no clear state store/verification in this module.
  4. MFA is not visibly enforced as a universal requirement for privileged users in these repos.

Recommendations​

  1. Define a unified auth architecture decision record (token types, trust chain, expiration policy, revocation behavior).
  2. Add automated route-security tests that fail if a new sensitive endpoint lacks auth dependency.
  3. Implement explicit OAuth state/nonce persistence and validation checks in callback paths.
  4. Introduce mandatory MFA for admin/super-admin operations at identity-provider or app-layer.
  5. Centralize authorization audit events for key operations (key creation, role changes, token minting).